Darren Reed writes: > >The underlying point is that LP provides a robust mechanism for > >implementing those sorts of features. It does _not_ mean that > >everything in the system has actually been reduced to the least > >privilege necessary. > > > >That's a lengthy process, and if you want to contribute to it, that's > >great. A lot has been done, but it's by no means complete today. > > > > Yes, I'd like to help - what's the right way to go about that? > File an RFE, take ownership and submit a fix?
Yes. Better yet if you can put more effort into it and scope out an entire area (rather than just one utility). > >Thus, a pointer to dlpi(7P) and a discussion of privileges on _that_ > >page makes sense to me. I'm not sure how a reference to privileges(5) > >in the libdlpi(3) documentation helps. (Should it also have a > >reference to libc(3LIB) and open(2)? I think those would be vacuous.) > > > > I agree. But I'm not 100% sure that it will always be the driver > that enforces the use of the security policy and depending on > how you view the architecture of Solaris, maybe it shouldn't? I don't believe it actually matters at this level. > The reason I'd say no driver that interfaces with hardware should > be involved in security policy enforcement is because drivers can > come and go - their role is to provide access to the hardware, not > enforce security policy. That's not quite true. What mechanisms are implemented in the system frameworks and what are implemented in the drivers may well change over time. There are some low-level design issues there (driver bits are often much finer grained than framework bits), and they may matter in some cases. But I would argue that this is really not the right way to look at things. The driver writer (like any other software writer) has to take security into consideration. If he evaluates everything and finds that the existing framework with no changes at all, then he can just say "see XXX for security details." If it doesn't or if he doesn't want to rely on it for some reason, he may well make other choices. > For example, if I go and look in the BGE driver, there is nothing > there that appears to use NET_RAWACCESS. If I use dtrace, the > call for checking privileges comes out like this: I think that misses the point. The driver writer delivers the devpolicy entry that causes the above stack trace to occur. He's the one who made the choice to add an entry there instead of calling drv_priv(9F) or some other function. Thus, it's the driver that's doing this, regardless of where the actual function call is made. What we don't have is a blanket policy throughout the system that says (in effect) "all network drivers have this set of security mechanisms." It just doesn't exist, and that's the root problem with trying to document a blanket policy with this library. > To bring this back to the original question, what then is the > correct point within the Solaris manual pages to mention that > privilege enforcement happens like this (not in the driver)? As far as the driver user is concerned, the enforcement does indeed happen "in the driver." The policy is that the open() fails if he doesn't have the right privileges. The fact that it was implemented using devpolicy rather than some other mechanism is merely an implementation detail. It might be an important detail for a system administrator (who might be able to modify that policy if it's not hard-coded), but the means of implementation makes no different for the application that uses the driver. -- James Carlson, KISS Network <james.d.carlson at sun.com> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
