Re: [RFC] add mount options to sysfs
From: Greg KH
Date: Wed May 18 2011 - 15:27:59 EST
On Wed, May 18, 2011 at 09:05:45PM +0400, Vasiliy Kulikov wrote:
> On Wed, May 18, 2011 at 09:39 -0700, Greg KH wrote:
> > On Wed, May 18, 2011 at 08:31:44PM +0400, Vasiliy Kulikov wrote:
> > > Currently there is no good way to effectively globally restrict an
> > > access to sysfs files. It's possible only to chmod the sysfs'
> > > root/directories to fully deny access to sysfs (sub-)tree to some users
> > > or chmod files after they are created. The latter approach is racy,
> > > however.
> > Why do you want to do this? What is in sysfs files that is not
> > gloabally ok to access? That should be fixed first, if at all, instead
> > of wanting to modify the whole sysfs tree, right?
> I don't hide the goal (I didn't find any other weird permissions, if
> you mean this). It is primary about additional global controlable
> layer of defining permission:
> 1) *IF* another sensitive file with weird permissions is found, mount
> option is IMO the best temporary workaround.
Maybe, but fixing the file would be the obvious solution.
> 2) Somebody might be worried about information leaks via world readable
> files - not strict bugs, but leaks in sense of local policy. See numerous
> discussions about hiding kernel addresses - there is no unified opinion
> about it. Some admins would be happy with denying access to almost all
> system information except some white list.
What file in sysfs "leaks" information like this? Please let us know
and we will be glad to fix that.
> > > The patch introduces sysfs mount options parsing and adds 4 new options:
> > > uid, gid, mode and umask. uid, gid, and umask are classical options,
> > > mode is a global restricting mode mask that defined the most relaxed
> > > possible file mode. E.g. if mode=0750 then "chmod 0664" changes file's
> > > permissions to 0640.
> > What is going to break if you do this? Have you tested it? I'd be very
> > worried about this.
> I've tested it on my laptop (I'm writing booted with this kernel). By
> default nothing has changed (umask=0000, mode=0777). Mounting sysfs
> with mode=0770 leads to the predictable state - no sysfs information is
> available to nonroot, e.g. no ACPI battery state. umask is tested with
> pluging a USB flash.
A usb storage device is hardly a huge consumer of sysfs files, sorry.
This would need a whole lot more testing before I would ever feel
confortable with it, even if I agreed that something like this should be
added (hint, I still don't.)
> mode has one advantage over umask. It is temporary - "mount -o
> remount,mode=0777" restores the initial state.
> I'd want to implement similar options for debugfs.
Again, lets fix the root problems here, if any, instead of adding
complexity and probably breaking systems by changing permissions without
anyone knowing about it.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/