James Carlson wrote: >Darren Reed writes: > > ... > >>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. >
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'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. > When writing this, I went and have a look at what we do for snoop and found we just do "uid=0" :( 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. >>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. > Indeed, I had the wrong impression of what could be achieved here using them. >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. > Yes, there is never enough testing :) >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? >>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.) > 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.) >>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. > 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. Darren
