[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110528071816.GA31763@openwall.com>
Date: Sat, 28 May 2011 11:18:16 +0400
From: Solar Designer <solar@...nwall.com>
To: owl-dev@...ts.openwall.com
Cc: Eugene Teo <eugeneteo@...il.com>,
Dan Rosenberg <dan.j.rosenberg@...il.com>
Subject: Re: segoon's status report - #1 of 15
Vasiliy, Eugene, Dan -
On Tue, May 24, 2011 at 07:12:46PM +0400, Vasiliy Kulikov wrote:
> I've posted an initial patch to LKML:
>
> https://lkml.org/lkml/2011/5/18/272
>
> Here I just posted the patch to LKML CC'ing relevant upstream people
> (here GregKH only) and CC'ing my mentor, Eugene - people on LKML are
> annoyed by long CC list sometimes. Should I CC you and/or owl-dev?
Initially, I thought that you'd be CC'ing me (as well as Eugene), but
now I have a better idea: setup a kernel-hardening list at Openwall and
start CC'ing it. Besides you, some others are also posting security
hardening patches to LKML, netdev, etc. They'd CC this same list as
well. Dan - would you CC such a list on your "Randomize kernel base
address on boot" thread (which I found by accident)? Would you want to
be on such a list?
As to your "add mount options to sysfs" thread on LKML, I just reviewed
it. While I am obviously on your side, I have some comments:
1. I dislike having the mount options affect explicit chmod by
user-space. I think they should affect the kernel's default perms only.
Here's a relevant excerpt from my message posted to owl-dev 2 months ago:
"It could be in the form of sysctl's or maybe mount options - mode, gid,
umask. Something like:
mount sysfs /sys -t sysfs -omode=700
mount proc /proc -t proc -ogid=110,umask=007
could be our default. The procfs umask would apply to user-related
entries in /proc only (most importantly, the /proc/<pid> directories),
whereas system-wide things like /proc/cpuinfo would stay world-readable.
If one wants to restrict access to those, they'd use mode=... instead,
which would apply to the procfs root directory entry. Well, OK, that's
confusing, and then we'd want umask to apply to /proc/net as well...
So maybe a differently named mount option or a sysctl will be better."
2. You gave two reasons to support these changes:
"1) *IF* another sensitive file with weird permissions is found, mount
option is IMO the best temporary workaround.
2) Somebody might be worried about information leaks via world readable
files - not strict bugs, but leaks in sense of local policy. See numerous
discussions about hiding kernel addresses - there is no unified opinion
about it. Some admins would be happy with denying access to almost all
system information except some white list."
I think you forgot to mention that sometimes being able to open() a
special file, such as a sysfs entry, is enough to gain an attack vector
to exploit a kernel infoleak bug. Not just bypass some local policy,
but achieve (semi-)arbitrary kernel memory read. This involves neither
a file with weird permissions (maybe 0644 was reasonable for some uses
of a certain sysfs entry), nor a restrictive local policy. And in some
cases those bugs could be worse than infoleak, too. To give an example,
the read vs. lseek races on procfs from some years back would be such
bugs. You could list this as a third reason, although for me it sounds
like the most important reason.
> > > * Rethink and discuss the usefullness of hiding /proc pid directories.
> >
> > What exactly do you mean by "hiding /proc pid directories"? Restricting
> > the perms on them (like in -ow patches and grsecurity) or actually
> > hiding the directories themselves (not revealing the PIDs and their
> > corresponding owner UIDs)?
>
> 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
> to identify whether there is a process with a specific pid. However, it
> might really hide process UID (/proc/PID/ owner).
>
> Eugene also noted that directories hiding might confuse antirootkits, etc.
I think that being able to optionally hide the directories makes sense
because it hides the UIDs - and thus the number of processes being run by
a particular user, and even whether a user runs any processes at all or
not. For example, seeing one /proc/PID entry with owner syslogd
suggests that the system is running syslogd as user syslogd. And not
having such an entry (yet being able to see them all) may suggest that
syslogd is running as root, and is thus a better target for attack.
However, when you don't see others' directories at all, you can't tell
whether syslogd is running as syslogd or root. This is just an example;
it could make more sense for other services, or/and for real users.
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.
