James Carlson wrote:
>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.
>
See coments below.
>>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.
>
Yes, I'd like to help - what's the right way to go about that?
File an RFE, take ownership and submit a fix?
>>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.
>
Not exactly.
>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?
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.
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:
# dtrace -n 'fbt::priv_policy:entry/execname == "cat"/{stack()}'
dtrace: description 'fbt::priv_policy:entry' matched 1 probe
CPU ID FUNCTION:NAME
0 11509 priv_policy:entry
genunix`secpolicy_vnode_access+0xc9
devfs`devfs_unlocked_access+0x97
devfs`devfs_access+0x99
genunix`fop_access+0x1a
specfs`spec_access+0x18
genunix`fop_access+0x1a
genunix`vn_openat+0x310
genunix`copen+0x1e5
genunix`open64+0x19
unix`sys_syscall32+0xef
(cat /dev/bge, as non-root, was used to generate the above.)
This took a minute or two to grok, but when I did, it made
complete sense.
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)?
Darren
