[kernel-hardening] /proc/PID directory hiding (was: [owl-dev] segoon's status report - #1 of 15)

[kernel-hardening] /proc/PID directory hiding (was: [owl-dev] segoon's status report - #1 of 15)

[Solar Designer]

Pavel, Vasiliy -

On Sun, May 29, 2011 at 02:07:58AM +0800, Pavel Labushev wrote:
> 24.05.2011 23:12, Vasiliy Kulikov wrote:
> 
> > 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
> 
> 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

Re: [kernel-hardening] /proc/PID directory hiding (was: [owl-dev] segoon's status report - #1 of 15)

[Vasiliy Kulikov]

On Sat, Jun 04, 2011 at 22:19 +0400, Solar Designer wrote:
> > 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()).

> 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.

Re: [kernel-hardening] /proc/PID directory hiding (was: [owl-dev] segoon's status report - #1 of 15)

[Solar Designer]

On Sun, Jun 05, 2011 at 12:20:47AM +0400, Vasiliy Kulikov wrote:
> On Sat, Jun 04, 2011 at 22:19 +0400, Solar Designer wrote:
> > 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.

> 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

[Pavel Labushev]

05.06.2011 04:20, Vasiliy Kulikov пишет:

>> 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()).

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

[Pavel Labushev]

>>> 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()).
> 
> 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.