[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/29360: vfs.generic.usermount and mount(8) general questions
The following reply was made to PR kern/29360; it has been noted by GNATS.
From: Elad Efrat <elad%NetBSD.org@localhost>
To: Antti Kantee <pooka%netbsd.org@localhost>, Manuel Bouyer
Subject: Re: kern/29360: vfs.generic.usermount and mount(8) general questions
Date: Sun, 6 Sep 2009 14:30:25 -0400
On Sun, Sep 6, 2009 at 2:21 PM, Antti Kantee<pooka%netbsd.org@localhost> wrote:
> On Sun Sep 06 2009 at 13:02:02 -0400, Elad Efrat wrote:
>> I agree with Antti here about the sysctl, but I want to replace the
>> root check, eventually. What do you guys think about replacing the
>> owner/root check with a kauth action that does the same in a
>> bsd44-suser listener?
> Well, sounds sensible in general, but just some food-for-thought: I wonder
> how much of an "ufs syndrome" you are creating for security code, i.e. how
> difficult will it be to implement a security model without copypasting
> "bsd44" and modifying a few bits here and there and eventually ending
> up with 20 slightly different copies of whatever the secmodel equivalent
> of rename is?
Funny that you ask: this is exactly the bit I removed from the reply. :)
Similar to how securelevel was separated from bsd44, I plan on doing
the same for suser, including removing any code that doesn't check
solely for euid 0. In other words, I want the securelevel secmodel to
only care about the securelevel variable and the suser secmodel to
only care about euid 0. Bsd44 will remain as a "grouping" entity for
both of them.
The remaining checks (tons of uid/gid/whatever comparisons, etc.) will
be moved to their own respective listeners in each subsystem --
similar to what Iain had done with the bluetooth code.
That way, we won't have to duplicate anything because the subsystem
itself will contribute the "default" access controls. Secmodels will
be able to implement only what they're designed to.
Main Index |
Thread Index |