Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.