Darren Reed writes: > >... or something like that. And the result is chaos for application > >writers. If the application depends on resources that may have > >varying requirements (e.g., both legacy and "new" drivers), there's > >really no good way to document what privileges that application might > >need to be granted in order to get its job done. > > > > If we're shipping any legacy drivers, I'd consider that a bug. > > Granted that doesn't hold for 3rd party developers, but again,
That's exactly the point. Many systems do in fact have drivers from third parties, and those drivers don't necessarily obey any new standards we've set. In fact, they don't _have_ to. > how would you, as a developer writing a network driver, know > that you should make use of various privileges in your code? 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. I'd pay more attention if it were a requirement (for example, if some customer of mine expressed a need to do "pfexec ifconfig" with some set of authorizations that work for bundled drivers), but less when it doesn't matter. > So there is work here for HCTS/VTS, to check if a network driver > requires or makes use of privileges(5) in order to enforce security. Unfortunately, neither of those really addresses the issue. HCTS doesn't actually do any validation of driver interfaces or of third party driver functionality. Instead, it focuses on high-level aspects such as system stability. (Whether that's the right focus or not is the topic of much discussion, but it's not headed there yet.) VTS is intended to test hardware, not software. It relies on private interfaces in the bundled software to invoke test modes in the hardware, and is used for finding broken wires and the like. It doesn't really help in testing software interfaces. Both are somewhat worthwhile for stress testing, but you're talking about functionality, which is different. Other than STC/STC2, I don't know of any packaged test suite that tests drivers in the way you're suggesting. And I don't think that STC/STC2 is really complete enough to do this today. (I don't know of any DLPI test suite, for instance.) More work is needed here. 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). > What I'd like to see us able to include would be a paragraph > (to start with what you had) that goes like this: > > "The calling application must have sufficient privilege (see > privileges(5)) to access the underlying driver node and, where > applicable, the individual functions implemented by that driver." That seems harmless. (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.) > Which is to say that if we don't have a common security standard > for, in this case, network drivers then we need one. Maybe. > Reading your reply, it sounds very much like a "there's nothing > for us to do here." I don't accept that. We need to find a > way to better expose the security features in Solaris so that > application developers can more accurately use them. The other > way to read your reply is that we've got no clue about what's > going on. I don't believe that is the case either. If _you_ feel you can do better, then have a whack at it. I'm not going to design such a thing here. > If we can't achieve better integration in our documention of the > implementation of privileges and how it integrates into the rest > of Solaris, then with the exclusion of customers that use TX, > privileges(5) is a white elephant. I don't want that to happen. Privileges(5) is no panacea. It does what it does -- but if someone is expecting it to tell him everything he might need to know, then I think he may be mistaken. The system is just much more complex. -- 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
