Re: kern/29360: vfs.generic.usermount and mount(8) general questions

[Elad Efrat <elad%NetBSD.org@localhost>]

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 
<bouyer%antioche.eu.org@localhost>, gnats-bugs%netbsd.org@localhost, 
        tech-kern%netbsd.org@localhost
Cc: 
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.
 
 Sounds okay?
 
 Thanks,
 
 -e.