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.