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.