Darren Reed writes: > >Honestly, if I were a third party driver writer, I would likely not > >use least privilege. The main problem is that the interfaces are not > >present on S9 and older systems, and thus represent a complication > >with little benefit to me or my customers. > > > > Oh :( > I'm not happy to hear you say that. They should represent a > chance for us to make Solaris more secure and thus to the > customer they should be able to worry less about a root > exploit compromising "everything".
I said I was being honest. ;-} What a driver writer cares about may well differ from what a system designer cares about or what an administrator observes. Unless there's some force applied, things change slowly, if at all. > I think it would be quite cool if we had "privs=net_rawaccess" > in there for "pfexec snoop". I've su'd more often just to run > snoop/tcpdump than to use ifconfig and tcpdump/snoop haven't > been free of security exploits. 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. > >On top of that, there's a relatively simple problem: I don't think we > >have any standards in this area. We don't have a canonical list of > >privileges a process must hold in order to manipulate particular > >classes of hardware devices, such as network interfaces. And it's > >possible that such a list is even at odds with good design practices > >(i.e., some drivers may do things that require more privilege than > >others). > > > > On the surface, this seems at odds with good software design. > But maybe we're still working out how it all fits together? I'm pointing out that local design choices may be at odds with global ones. We've seen this before with (for example) the sorts of direct memory mapping interfaces used by graphics adapters. > >(If that's not just patently obvious, though, you probably shouldn't > >have "-ldlpi" on your compilation command line. You're in way too > >deep.) > > > > To you and me, sure. But my concern is that if you're porting > your network monitoring application or whatever from Linux or > BSD or something else to Solaris, you may not feel like you're > in too deep but still be otherwise completely ignorant to this > part of Solaris (and quite possibly never discover it.) In that case, you're no better or worse off than you were before. Your application will still run fine if the user becomes all-powerful 'root' first. Your documentation (which probably says "su root" or "sudo" or just "superuser") will still be correct, at least on an unmodified system. What will be missing is that your application could do better on Solaris -- it could run with fewer privileges, and allow users with fewer authorizations to use it. That's an enhancement not a requirement, and it requires a bit of understanding of what things are available on Solaris. So, I don't see a problem here. > Definately. What I'm thinking is that we could do with some > more signposts that point to privileges(5) to increase the > general awareness of this feature. Hopefully increased > awareness will lead to increased use, resulting in people > ending up with systems that are more secure because the > applications that otherwise needed to be root understand > that this isn't necessary. Maybe. But I also don't want to see the system littered with pointless or confusing references, either. In this case, libdlpi really doesn't enforce anything about security, nor does it require any sort of special privileges. It's the drivers that do this. 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.) -- 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
