[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 31 May 2011 19:39:39 +0400
From: Vasiliy Kulikov <segoon@...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
Solar,
On Sat, May 28, 2011 at 11:18 +0400, Solar Designer wrote:
> 1. I dislike having the mount options affect explicit chmod by
> user-space. I think they should affect the kernel's default perms only.
What do you mean? sysfs' "umask" does exactly you want - it changes the
default kernel's umask, all new kobjects will be created with this
umask. "mode" is just a simplifying thing that affects only a view - a
mount point. If it is remount'ed with more relaxed "mode", all
kobjects' permissions will be restored. Do you think "mode" is
redundant and confusing?
> 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
Then maybe call it "pmode", not umask? Because old pid directories are
affected too, however, umask should affect only newly created files.
And for hiding directories - "phide"/"nophide".
> If one wants to restrict access to those, they'd use mode=... instead,
> which would apply to the procfs root directory entry.
Does it make sense? Everything but PID directories should be permanent,
all /proc files may be freely chmod'ed via boot script. Is there any
drawback of doing it in userspace?
> 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.
This can be superset'ed by "any bugs in sysfs handlers" with some
significant examples.
> 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.
Agreed, now I share the same opinion.
Thank you,
--
Vasiliy
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
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.
