Re: Proposed change to route(4) sockets to make them available to non-superuser

From: Garrett Wollman (wollman@khavrinen.lcs.mit.edu)
Date: 09/05/01 

Date: Wed, 5 Sep 2001 12:47:16 -0400 (EDT)
From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
To: Robert Watson <rwatson@FreeBSD.ORG>

<<On Tue, 4 Sep 2001 16:47:42 -0400 (EDT), Robert Watson <rwatson@FreeBSD.ORG> said:

> 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.

I would argue that any file descriptor is, in and of itself, a
(somewhat limited form of) credential. Presumably the 4.3BSD
developers thought so as well, since they called the
file-descriptor-passing mechanism in Unix-domain sockets SCM_RIGHTS
and not SCM_PASSFDS or something similar.

> 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.

Indeed. My general objection is not to using the caller's credentials
-- although I think the whole issue with cached credentials needs to
be rethought -- but to the reintroduction of references to `curproc',
which I spent a good deal of time several years ago stamping out.

> 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.

An alternative model would be to explicitly associate privilege with
file descriptors, and provide some mechanism to explicitly downgrade a
descriptor's associated privilege. We actually did this: I introduced
a socket option which, when set, would clear the SS_PRIV flag on the
socket. Eventually this was forgone in favor of a true credential
check in the places where SS_PRIV was formerly used.

-GAWollman

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

Relevant Pages

  • Re: Proposed change to route(4) sockets to make them available to non-superuser
    ... > on the basis of credentials rather than a process, ... and others based on the current socket credential. ... unprivileged process, and know that the unprivileged process can't rebind ... privileged process. ...
    (FreeBSD-Security)
  • Re: mlock(2) for ordinary users
    ... Whilst this is a valid concern, there are good security reasons for allowing a user to lock small amounts of memory to ensure that sensitive information don't wind up on swap devices. ... When pages become unlocked, are any credentials that have ... In the case of socket limits, for example, we actually keep a reference to the allocating credential in the struct socket so that when the socket is freed, we can credit the resources back to the original credential, not to the credential of whatever process last references the socket. ...
    (freebsd-arch)
  • Proposed change to route(4) sockets to make them available to non-superuser
    ... This allows *anyone* to open any raw socket. ... Since we already save the credentials of the process ... we should do the access-control on the basis ... (Consider, for example, a daemon which opens its sockets ...
    (FreeBSD-Security)
  • Re: Someone help me understand this...?
    ... relating to the delivery of "unexpected signals". ... while holding root privilege, which means that the process may well have ... debugging of applications that have changed credentials and now appear ...
    (freebsd-current)
  • Re: Remote WMI scripting problems
    ... Server databases, where the actual backup process uses the server computer ... The privilege is called wbemPrivilegeBackup. ... almost as if it exec's it with SYSTEM credentials. ...
    (microsoft.public.windows.server.scripting)