Re: RFC: [PATCH] SCM_CREDS support

[Samuel Thibault]

Svante Signell, le Thu 24 Oct 2013 15:38:11 +0200, a écrit :
> > Well, the question is quite simple: what happens when the sender
> > provides faked ports, e.g. pointing to other proc/auth servers?  That's
> > where having to explain how the patch is working would possibly even
> > work out the security issues.
> 
> How could it point to other proc/auth servers? The receiver is using the
> ports of the same proc server.

But which proc server.

> Are you considering more than one instance running?

The user who started the sender could have very well started its own
proc server, yes.

> This is communication on a local socket, and the.
> socket read/write mode is controlling the access to it.

That does not mean that the receiver trusts the sender completely.
That's exactly one of the reasons why SCM_CREDS exists.

> In the
> implementation only the same user and root could send. for other users
> the socket permission has to be changed from srw-r--r-- to srw-r--rw-

That is completely irrelevent to SCM_CREDS. A receiver can very well
want all users to be able to connect to it, and behave differently
depending on who connected to it (root, admin, etc.)

> > > @@ -106,6 +110,33 @@
> > > +  /* SCM_CREDS support: Create and send the ancillary data  */
> > > +  cmsg = CMSG_FIRSTHDR (message);
> > > +  if (cmsg != NULL && cmsg->cmsg_level == SOL_SOCKET && cmsg->cmsg_type 
> > > == SCM_CREDS)
> > > +    {
> > > +      for (; cmsg; cmsg = CMSG_NXTHDR (message, cmsg))
> > > + {
> > > +   ucredp = (struct cmsgcred *) CMSG_DATA(cmsg);
> > > +   process_t proc = getproc ();
> > > +   auth_t auth = getauth ();
> > > +   nports = 2;
> > > +   ports = __alloca (nports * sizeof (mach_port_t));
> > > +   ports[0] = proc;
> > > +   ports[1] = auth;
> > 
> > So what if here we providing the ports to other proc/auth servers?
> 
> If so they have to guess exactly which ports are used by the running
> instance of proc and auth, or??

Sure.  But that's not difficult when the user of the application which
sends the cred has started proc and auth itself.

Again, nothing enforces the user to use libc's sendmsg() to send the
SCM_CREDS message. The user can very well write his own program that
starts a proc server, and then emits the sendmsg RPC.

> > > +      goto label;
> > 
> > Why skipping SCM_RIGHTS support?  The message may contain *both*
> > SCM_RIGHT and SCM_CREDS, we have to support that.  Likewise on the
> > receiver side.
> 
> I have never seen any application using that.

That doesn't mean that we can avoid supporting it.

> > > +    err = __USEPORT (PROC, __proc_getpids (proc, &rpid, &rppid, 
> > > &orphaned));
> > > +    if (err)
> > > +      goto finish;
> > > +    if (rpid != pid )
> > > +      {
> > 
> > So here is the security concern: this is asking the proc port of the
> > sender what is the pid of sender. But what if the proc server of the
> > sender is a fake and tells us lies?  You'd need to check that the
> > process behind `proc` is the same as the process behind the receiver's
> > proc server.
> 
> How?

I don't know RPCs enough to answer.

> What about the _hurd_check_ids() call?

That is a completely different thing: _hurd_check_ids talks with the
auth server of the process, which it trusts.  Your code is talking with
proc/auth servers indicated by the sender, which we don't want to trust.

> > So I'd say a completely different way is needed to check the pid of the
> > sender. The matter here is that only pflocal has a port to the sender,
> > the receiver doesn't have one. Another noticeable thing is that the
> > receiver trusts pflocal, so if pflocal provides information about the
> > sender (such as a task port of the sender), the receiver can trust it,
> > and safely use proc_task2pid etc. to get information about it from its
> > own proc and auth servers.  So probably adding something to pflocal can
> > provide a solution.
> 
> Can you elaborate?

I mean something like extending pflocal RPCs, to include the task port
of the sender along the socket_send/recv path.  I however don't know how
the pflocal side of S_socket_send can know which task emitted the RPC.
That's probably the main problem to be solved.

> How to modify proc and auth servers (or write simple code) to fake
> stuff?

You can for instance simply use the hurdish fakeroot. The fakerooted
process will thoughfully think it's root, and send the port to the faked
auth, and if the receivers asks that auth server, it'll of course say
the fakerooted process is indeed root.

Samuel