Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 31 May 2011 19:39:39 +0400
From: Vasiliy Kulikov <>
Cc: Eugene Teo <>,
	Dan Rosenberg <>
Subject: Re: segoon's status report - #1 of 15


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,


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.