On Thu, 30 Aug 2001, Garrett Wollman wrote:

> <<On Thu, 30 Aug 2001 20:41:32 +0300, Ruslan Ermilov <ruFreeBSD.ORG> said:
>
> > + if (rtm->rtm_type != RTM_GET && so->so_cred->cr_uid != 0)
> > + senderr(EACCES);
>
> I'm certain rwatson would object to this. suser_xxx() allows checking
> on the basis of credentials rather than a process, so that's what should
> be used. In any case, the correct error is EPERM, not EACCES.

There are a number of situations where it's desirable to authorize based
on the current process, and others based on the current socket credential.
So far, the only interesting case I know of for using process rather than
socket credentials is wrt bind() and connect(), where you want to use the
process credential when changing the port/address binding--this permits a
privileged process to share a socket bound to a low port with an
unprivileged process, and know that the unprivileged process can't rebind
it to another low port number, but must use the one provided by the
privileged process. Likewise, a concerning scenerio is one where a socket
is provided by a privileged process to an unprivileged process as its
stdio on execve() -- you don't want the child process to be able to
manipulate that socket in undesirable ways.

Generally, routing sockets aren't passed from process to process, and any
process doing so should beware the consequences of poorly defined access
control policies. My suspicion is that this class of socket operations
should be authorized using the credential of the current process, but I'd
be interested to know what (if anything) other operating systems do to
address this problem.

Cached credentials in open files/sockets/etc introduces a lot of
complication to the UNIX-like security model. I suppose the more
conservative view would be that, with the exception of "traditional" file
operations (read/write/close), all operations on devices, sockets, et al,
should use current process credentials rather than cached credentials.
I'm not sure I'm comfortable with that, since I haven't thought through
all the cases, but it seems "safe".

Robert N M Watson FreeBSD Core Team, TrustedBSD Project
robertfledge.watson.org NAI Labs, Safeport Network Services

To Unsubscribe: send mail to majordomoFreeBSD.org
with "unsubscribe freebsd-security" in the body of the message

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]