[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20111110190030.GC23582@openwall.com>
Date: Thu, 10 Nov 2011 23:00:30 +0400
From: Solar Designer <solar@...nwall.com>
To: owl-dev@...ts.openwall.com
Subject: Re: procfs and tty timing infoleaks
Vasiliy,
On Wed, Nov 09, 2011 at 09:50:17PM +0400, Vasiliy Kulikov wrote:
> Given latest LKML discussions about scheduler and timestamp infoleaks,
> I think we can break backward compatibility via patching procps in Owl.
> In details, I propose:
>
> 1) restrict access to /proc/$PID/{stat,sched,schedstat}. Patch procps
> to gracefully handle -EPERM as if all stats are zeroes.
With hardening changes similar to what we had in 2.4.x-ow, /proc/PID
directories will have perms on them restricted - and procps handles this
just fine. Are you referring to the case when this hardening feature is
disabled (so users can see processes of other users), yet we want to
deal with certain kinds of infoleaks anyway (such as with those related to
keystroke timings)? I don't mind, but I think our priority should be
getting the hardening measures equivalent to 2.4.x-ow's into our OpenVZ
kernels first (RHEL5 and/or RHEL6-branch). In practice, I expect that
on most systems where the keystroke timing infoleaks matter, an
equivalent of 2.4.x-ow's CONFIG_HARDEN_PROC will be enabled, so issues
with individual entries under /proc/PID/ won't matter much (well, maybe
only for admin users in group proc).
> 2) chmod /proc/{interrupts,stat} to 0400.
OK for /proc/interrupts. I'm not sure about /proc/stat. Doesn't this
break e.g. top(1)? I think it makes sense for users to be able to see
overall system load even when they can't see processes of other users.
So we might need to filter /proc/stat contents instead.
BTW, somehow /proc/stat is not chmod'able from userspace:
root@owl:~ # chmod 400 /proc/stat /proc/interrupts
chmod: changing permissions of `/proc/stat': Operation not permitted
root@owl:~ # ls -l /proc/stat /proc/interrupts
-r-------- 1 root root 0 Nov 10 22:38 /proc/interrupts
-r--r--r-- 1 root root 0 Nov 10 22:38 /proc/stat
> 3) fill zeroes in tty mtime/atime fields on stat() family syscalls.
Would you check for S_ISCHR() and for known tty majors in *stat()?
Maybe setting mtime and atime to ctime will be better?
And even then, what about reporting by tools such as w(1)? Don't they
rely on tty mtime's for figuring out users' idle time? So I think
you'll need to report the actual mtime with some granularity - e.g.,
with 5-second granularity (we can have this configurable via sysctl).
Yes, this is a variation of Linus' idea re-applied from byte counters
to timestamps.
> Alternative - not to patch these ourselves too and propose procfs patch
> upstream; after we get ACK/NACK, backport it to RHEL5 kernel and to RHEL6
> after we move to it.
For Owl, we primarily need an equivalent of 2.4.x-ow's hardening
features - not only for procfs, but overall. Once we have those, it
will make sense to enhance them and add to them. Until then, I feel
that we'd be using time non-optimally by plugging individual infoleaks
such as those you found recently. I understand that you needed that for
demonstration to upstream, but I feel that for Owl the priority is
different. On the other hand, it's weird to publicize those infoleaks,
get CVE ids for them, get other distros to patch them, yet not hurry to
do the same ourselves. ;-) So I think we should actually do both:
hurry up to get the basic hardening functionality from 2.4.x-ow into our
OpenVZ kernels and plug those additional issues. Would you like to work
on this, including for RHEL5 kernels?
Thanks,
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
