On 2004-11-30 mouse@Rodents.Montreal.QC.CA wrote:

> > 3) Make the simple kernel change I described earlier, such that no
> >    device node on any _writable_ filesystem can be used; that is,
> >    embed this policy in the kernel.
>
> That's not enough.  Nothing then stops your putative attacker from
> creating an MFS with device nodes in it and then mounting it RO.

  If you can create device nodes on writable disks you could also remount
a writable ffs partition RO.

> > But it seems to me that devfs breaks this model completely, because
> > it will always be possible to hook up a new devfs,
>
> Maybe that's what we need.  "sysctl -w kern.devfs.more_mounts=0"?
>
> That is, provide a way to totally disable mount(2) _for devfs_?
>
> > and there's no way to really require that the config file have any
> > particular attribute, whether immutable, present on nodev filesystem,
> > or _whatever_ -- unless the parser is in the kernel, not userland.
>
> Not quite.  For example, if devfs could be mounted only by PID 1, that
> could perhaps do it.  (Yes, that as a bunch of other problems.
> Certainly pushing the parser into the kernel is the _best_ of the ones
> that I can think of; it's just not the _only_ one.)

  I guess if securelevel definitions are (or might be) changed this could
be an issue.

  An extention of the PID 1 idea would be a inheritable process flag that
can only be downgraded that allows access to special priviledges
(including mount, and possibly all access to the physical disks).  Init
first starts rcsecure with this flag in priviledged mode, then downgrades
it and runs rc.  This opens you up to potential attacks on the priviledged
processes.  You could also have only-further-restrictable kernel enforced
"least restrictive permissable device permissions" that might catch more
cases (maybe this is what you had in mind with the filter suggestion), but
this may not be worth the implementation cost.

  I don't think a kernel parser would be that bad.  I think the quota code
was previously mentioned as a possible model for this.

  Another possibility is that new symbolic "device special files" could be
added but disabled by default and those who wish could use that at the
cost of file system incompatability.  Or the current numerical code could
be preserved, but eventually remove the standard numerical map while
leaving some means to configure it and enable use of numerical nodes if
desired.  Some of the possible implementations would result in minimal
unique code for this usage.

Matthew Orgass
darkstar@city-net.com