Re: Extended SCM_RIGHTS for AF_UNIX sockets

Malcolm Beattie (malcolm.beattie@computing-services.oxford.ac.uk)
23 Jul 1996 12:02:25 GMT

In article <9607221601.AA11176@gnu.mc.xerox.com>,
Marty Leisner <leisner@sdsp.mc.xerox.com> wrote:
>>
>> We can now pass file descriptors down Unix domain sockets with
>> an SCM_RIGHTS control messages in sendmsg() but can't easily
>> tell for *certain* who sent them to us. [Guesses made via
>> getpeername and stat are subject to minor attacks.] SysV file
>> descriptor passing uses a STREAMS I_SENDFD and the receiver gets
>> the sender's euid and egid. I'd like to add something like
>> SCM_XRIGHTS to Linux which would behaves like SCM_RIGHTS on the
>> sender side but the receiver gets a control message containing:
>> uid_t uid;
>> gid_t gid;
>> pid_t pid;
>> int fd[...];
>> instead of just the array of descriptors. Notice that the trivial
>> case is also useful. The sender can send zero file descriptors with
>> SCM_RIGHTS and the receiver can verify who sent the message, both
>> uid/gid and the PID of the sender. Would anyone mind if I added this
>> extension?
>>
>
>I don't see why its necessary...you can devise a protocol where this
>information
>is in the data field...
>
>Passing fds have to be buy cooperating applications...you can put in id's with
>the data if you want to ...but you can spoof it...

The spoofing is exactly the point. Just because two processes
cooperate doesn't mean they should trust each other. I want a process
serving out file descriptors and it must be able to guarantee the
access rights of the other end. Just as the open(2) syscall doesn't
let you give an argument containing the uid you claim to be, this
mustn't either ;-).

>Note I have no experience where we want to do this...

I'm adding a syscall mask to the kernel and writing wrapper functions
for some syscalls which get their file descriptors from a "virtual
machine" serving daemon which can vet access to files, sockets and
so on. That way, you can run any potentially-unsafe program in a
secure, restricted environment without being restricted to Java,
safeperl, safetcl or whatever and without "buffer overrun" errors
mattering. Because the syscalls are trapped on kernel entry, it
doesn't matter if you can trick the program to execute arbitrary
machine code. Since the syscall mask is kernel code, it's already
Linux-specific so I don't mind too much that the SCM_XRIGHTS
control message is non-portable. Heck, BSD have already changed
the access-rights passing API from 4.3 to 4.4 and since it's now
supposed to be extensible, I don't feel bad about new control
message types. It's analogous to the Linux SOCK_PACKET and other
Linux-specific ioctls.

--Malcolm

-- 
Malcolm Beattie <mbeattie@sable.ox.ac.uk>
Oxford University Computing Services
"Widget. It's got a widget. A lovely widget. A widget it has got." --Jack Dee