[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110317105918.GA6246@albatros>
Date: Thu, 17 Mar 2011 13:59:18 +0300
From: Vasiliy Kulikov <segoon@...nwall.com>
To: owl-dev@...ts.openwall.com
Subject: Re: sysfs security risks (was: VLANs in Owl way?)
On Wed, Mar 16, 2011 at 02:54 +0300, Solar Designer wrote:
> > Permissions of some sysfs files were too restricted not long
> > ago:
s/restricted/relaxed/ :-)
> For example, when we were still using 2.4 kernels, a set of lseek(2) vs.
> read(2) races was discovered.
Do you mean this?
v2.4.32:
/* VERIFY_WRITE actually means a read, as we write to user space */
fn = (type == VERIFY_WRITE ? file->f_op->read :
(io_fn_t) file->f_op->write);
...
nr = fn(file, base, len, &file->f_pos);
v2.6.38:
loff_t pos = file_pos_read(file);
ret = vfs_read(file, buf, count, &pos);
file_pos_write(file, pos);
In 2.6 either lseek's resulting pos or read/write's resulting pos will
be written to the file->f_pos. One instance of lseek/write may not
influence on behavior of other's because everybody owns his "local"
fpos.
> A reasonable option is to mount sysfs, but restrict access to it to root
> or to a group. This may be achieved by introducing an extra directory
> layer (above the mountpoint)
One note - then /sys/ must be a symlink to the real mountpoint as all
userspace tools don't look at mtab, but use hardcoded path.
> I'd rather not have us mount sysfs by default until we have to and we've
> done something like the above.
I don't see any strong reason to use sysfs by nonroot processess.
Almost all sysfs' information is about either hardware or the system
itself.
Thanks,
--
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments
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.
