On 7 May 2001, Dag-Erling Smorgrav wrote:
> Alfred Perlstein <[EMAIL PROTECTED]> writes:
> > The silly part of it is that the socket's initial credentials
> > might be different than the holder's credentials.
>
> That's a feature, just like you can open /dev/io as root, then drop root
> privs and do direct I/O to your heart's content even if you're no longer
> root.
However, a lot of device drivers do checks on p->p_ucred (or indirectly
via suser(p)) rather than using the cached credential in the struct file.
This is arguably wrong or evil, but since the driver writers really feel
like doing that, I suppose all we can do is shoot them, not stop them.
There are actually a number of places in netinet and netinet6 where some
checks are performed on so->so_cred while others are performed on
p->p_ucred. This is to restrict the rebinding of sockets by processes,
preventing the following scenario:
(1) privileged process p1 creates socket s1, and binds it to (PF_INET,
IPPROTO_TCP, 80)
(2) privileged process p1 transfers s1 to unprivileged process p2 (or
drops privileges)
(3) unprivileged process p2 rebinds to (PF_INET, IPPROTO_TYPE, 22)
Getting the checks for that right is hard, as the definition of correct is
a bit ambiguous, and it's not clear all the code in there is "right" at
this point. It's one of the things on the list of authorization
components to review. Generally speaking, I'd much rather the cached
credential was used, but understand why it's not in this scenario.
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED] NAI Labs, Safeport Network Services
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
