[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20111110204312.GA24453@openwall.com>
Date: Fri, 11 Nov 2011 00:43:12 +0400
From: Solar Designer <solar@...nwall.com>
To: owl-dev@...ts.openwall.com
Subject: Re: procfs and tty timing infoleaks
Vasiliy,
On Fri, Nov 11, 2011 at 12:16:36AM +0400, Vasiliy Kulikov wrote:
> On Thu, Nov 10, 2011 at 23:00 +0400, Solar Designer wrote:
> > > 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)?
>
> Yes, that's why we should patch top(1) first. I guess rounding /proc/stat
> would break top if update frequency is high, i.e. division on rounded 0, 1,
> 2 instead of precise numbers will lead to very inaccurate results. It
> will lead to more harm than benefit.
This is not what I meant by filtering /proc/stat. I thought that if we
let the current user read /proc/stat at all, it should have precise
values on the cpu* lines, but all zeroes on the intr line (since it
almost directly reveals individual keystrokes on the directly connected
keyboard and on serial lines). Maybe we also need to show ctxt as zero,
because increases in the number of context switches may reveal
keystrokes with multi-process apps (such as services with privilege
separation yet with interactive password input, and GUIs).
> > 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.
>
> Well, I think Linus' idea in this case is indeed good - it will break
> very precise statistical match. However, I'm hesitating to estimate the
> risk of such rounded counters/timestamps...
I think it's different for counters vs. timestamps. With a counter, as
you correctly pointed out, the observer may know when a certain precise
value was finally exceeded. Moreover, if the observer is also an active
attacker, he/she/it can bring the counter close to the threshold, then
observe a certain event occur as if there was no granularity. However,
with timestamps and with no ability to affect the system time, nor
keystrokes on another tty, I think these risks do not apply. It will
remain possible for an observer to determine whether another user is
idle or not, but that's on purpose (although we may want to introduce a
way to disable that - perhaps a sysctl setting that would set tty
mtime/atime to ctime instead of merely increasing the granularity).
> I suggest another variant: respin HARDEN_PROC on LKML, explicitly noting
> that it doesn't fix suid/sgid hole, i.e. it's possible to keep fd of 0444
> file (like /proc/$PID/cmdline), run suid binary and still read cmdline.
> FWIW, Spender says he's aware of this bug in Grsecurity and he thinks it
> is not important (in attack non-root user => root via this suid there is
> not much non-root user may learn via these procfs files).
I'm fine with this plan and I agree with this assessment.
We need the entire functionality of 2.4.x-ow (and then more) in our
OpenVZ kernels anyway. I understand that you want to integrate it in a
manner preferably similar to what gets accepted into mainline, if
anything. This makes sense to me.
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.
