/proc/PID directory hiding (was: [owl-dev] segoon's status report - #1 of 15)
A message that is not in the archive (sent off-list or not yet received): 20110518150601.GA2921@albatros
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): 20110524151246.GA3401@albatros
A message that is not in the archive (sent off-list or not yet received): [email protected]
Pavel, Vasiliy -
Quoted 8 lines · Pavel Labushev
Quoted 5 lines · Vasiliy Kulikov
I've implemented restricted perms, but didn't do actual hiding directories. In grsecurity it is implemented by hiding directories from processes that cannot access them.
I think it may be defective by design because there are many other ways
Quoted 7 lines
It is:
$ python -c 'import os; print os.stat("/proc/1")' posix.stat_result(st_mode=16744, st_ino=535821L, st_dev=3L, st_nlink=6, st_uid=0, st_gid=0, st_size=0L, st_atime=1306605485, st_mtime=1306605485, st_ctime=1306605485)It's a known flaw and AFAIR it was considered irrelevant.
Is the above on grsecurity?
I think we may choose to restrict more than just directory listing - that is, have these entries invisible even when referenced by full pathnames.
As to probing for PIDs with syscalls such as kill(2), we may deal with that as well (but we'd need to consider potential performance impact, as well as timing attacks), or may choose not to do it. Arguably, we primarily want to hide UIDs/GIDs of running processes, not their PIDs.
Alexander
Quoted 9 lines · Solar Designer
Quoted 7 lines
It is:
$ python -c 'import os; print os.stat("/proc/1")' posix.stat_result(st_mode=16744, st_ino=535821L, st_dev=3L, st_nlink=6, st_uid=0, st_gid=0, st_size=0L, st_atime=1306605485, st_mtime=1306605485, st_ctime=1306605485)It's a known flaw and AFAIR it was considered irrelevant.
Is the above on grsecurity?
No, grsecurity hides uid/gid from both *stat*(2) and getdents*(2) functions (implemented as proc_pid_readdir() and pid_getattr()).
Quoted 2 lines
As to probing for PIDs with syscalls such as kill(2), we may deal with that as well
I'd not do this. There are too many paths using pids, I don't think there is some universal way (read: a bottleneck) to filter all accesses. And the award is not too high to bother.
Thanks,
Vasiliy.
Quoted 6 lines · Vasiliy Kulikov
Quoted 2 lines · Solar Designer
As to probing for PIDs with syscalls such as kill(2), we may deal with that as well
I'd not do this. There are too many paths using pids, I don't think there is some universal way (read: a bottleneck) to filter all accesses.
Something like this is done for containers, but I agree with you.
Quoted 1 line
And the award is not too high to bother.
Yes, perhaps, and it'd be difficult to avoid timing leaks.
Anyhow, this would be a separate task. Let's deal with the filesystems first, and then proceed with other hardening measures already implemented in patches and needing proper submission upstream.
Alexander
Re: [kernel-hardening] /proc/PID directory hiding
In reply to Vasiliy Kulikov05.06.2011 04:20, Vasiliy Kulikov пишет:
Quoted 4 lines
Quoted 1 line
Is the above on grsecurity?
No, grsecurity hides uid/gid from both *stat*(2) and getdents*(2) functions (implemented as
proc_pid_readdir()andpid_getattr()).
Yes, it's on grsecurity. Just try it and see.
$ uname -r 2.6.39-grsec $ find /proc -maxdepth 1 -type d -name 1 $ ls -ld /proc/1 dr-xr-x--- 6 root root 0 Jun 4 21:05 /proc/1
Re: [kernel-hardening] /proc/PID directory hiding
Quoted 5 lines
Quoted 4 lines
Quoted 1 line
Is the above on grsecurity?
No, grsecurity hides uid/gid from both *stat*(2) and getdents*(2) functions (implemented as
proc_pid_readdir()andpid_getattr()).
Quoted 7 lines
Yes, it's on grsecurity. Just try it and see.
$ uname -r 2.6.39-grsec $ find /proc -maxdepth 1 -type d -name 1 $ ls -ld /proc/1 dr-xr-x--- 6 root root 0 Jun 4 21:05 /proc/1
Fixed in the latest grsec patches.