Re: Getting PID of socket client

[Jilles Tjoelker]

On Sun, Jul 09, 2017 at 02:07:06PM +, Johannes Lundberg wrote:
> That code gets the child's pid from the fork command. That's is not
> available in my case (Wayland client connects to Wayland server via unix
> socket).

> I can understand the security issue.. hmm will dig further tomorrow..

It seems like what Wayland wants is not a security feature, but a
feature to prevent people from building things that will not work in a
future more secure world. In this future world, operations like making a
screenshot would be privileged.

Even if the PID race is solved, it remains trivial to fake the check
(for example, fork a process that sends the initial message and then
immediately execs a "privileged" binary, or use ptrace to attach to a
"privileged" binary or launch a new copy of a "privileged" binary).

With regard to security, it would be equivalent to have the client send
the name of its binary to the server. Putting this into a low-level
Wayland library would deter people from faking the check to do things
that will not work in the future more secure world. I don't know how
invasive this would be, though.

One possible implementation of the future more secure world would be
per-application UIDs a la Android. Another one would be
Capsicum-sandboxed applications where applications receive their Wayland
sockets pre-connected by code that tells the Wayland server the
application identity.

-- 
Jilles Tjoelker
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Getting PID of socket client

[Jilles Tjoelker]

On Sun, Jul 09, 2017 at 05:43:22PM +0100, David Chisnall wrote:
> On 9 Jul 2017, at 14:25, Stefan Ehmann  wrote:

> > Don't why the structs are not compatible, maybe because:
> > "The process ID cmcred_pid should not be looked up (such as via the
> > KERN_PROC_PID sysctl) for making security decisions.  The sending
> > process could have exited and its process ID already been reused for
> > a new process."

> Note that having the kernel provide a process descriptor instead of a
> PID would allow the userspace process to have race-free access to the
> PID.

This is an interesting idea, but would require quite a few changes.

First, current process descriptors act as an artificial parent process,
suppressing the normal SIGCHLD to the parent and not being matched by a
wildcard waitpid() or similar function. A new kind of process descriptor
would have to be added which leaves this behaviour unchanged and could
exist in parallel with a process descriptor from pdfork().

Second, pdgetpid() makes no guarantees whether the process ID still
exists. It should not make them either for this case, since this would
allow another user to hold onto process slots for RLIMIT_NPROC. The only
solution would be to add variants of the necessary calls that take a
process descriptor instead of a process ID.

-- 
Jilles Tjoelker
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Getting PID of socket client

[David Chisnall]

On 9 Jul 2017, at 14:25, Stefan Ehmann  wrote:
> 
> Don't why the structs are not compatible, maybe because:
> "The process ID cmcred_pid should not be looked up (such as via the
> KERN_PROC_PID sysctl) for making security decisions.  The sending process 
> could have exited and its process ID already been reused for a new process."

Note that having the kernel provide a process descriptor instead of a PID would 
allow the userspace process to have race-free access to the PID.

David

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Getting PID of socket client

[Johannes Lundberg]

That code gets the child's pid from the fork command. That's is not
available in my case (Wayland client connects to Wayland server via unix
socket).

I can understand the security issue.. hmm will dig further tomorrow..

Thanks for the info!


On Sun, 9 Jul 2017 at 15:26, Stefan Ehmann  wrote:

> On 09.07.2017 11:52, Johannes Lundberg wrote:
> > Hi
> >
> > Yeah I forgot to mention the LOCAL_CREDS.
> > It does not return the PID of the client process but i guess it could be
> > expanded to include that instead of adding another option for that.
>
> I was only skimming the man page. Didn't see that cmsgcred contains the
> PID, but sockcred does not. Of course the PID in my sample output is
> also wrong (the UID is printed instead of the PID):
>
> > $ ./unixstrserv02
> > PID of sender = 1001
>
> Don't why the structs are not compatible, maybe because:
> "The process ID cmcred_pid should not be looked up (such as via the
> KERN_PROC_PID sysctl) for making security decisions.  The sending
> process could have exited and its process ID already been reused for a
> new process."
>
> According to the commit log LOCAL_CREDS was obtained from NetBSD but I
> didn't investigate further.
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Getting PID of socket client

[Stefan Ehmann]

On 09.07.2017 11:52, Johannes Lundberg wrote:

Hi

Yeah I forgot to mention the LOCAL_CREDS.
It does not return the PID of the client process but i guess it could be 
expanded to include that instead of adding another option for that.


I was only skimming the man page. Didn't see that cmsgcred contains the 
PID, but sockcred does not. Of course the PID in my sample output is 
also wrong (the UID is printed instead of the PID):



$ ./unixstrserv02
PID of sender = 1001


Don't why the structs are not compatible, maybe because:
"The process ID cmcred_pid should not be looked up (such as via the
KERN_PROC_PID sysctl) for making security decisions.  The sending 
process could have exited and its process ID already been reused for a 
new process."


According to the commit log LOCAL_CREDS was obtained from NetBSD but I 
didn't investigate further.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Getting PID of socket client

[Johannes Lundberg]

Hi

Yeah I forgot to mention the LOCAL_CREDS.
It does not return the PID of the client process but i guess it could be
expanded to include that instead of adding another option for that.


On Sun, Jul 9, 2017 at 11:47 AM, Stefan Ehmann  wrote:

> On 09.07.2017 10:03, Johannes Lundberg wrote:
>
>> Hi
>>
>> Without altering the client code (i.e. adding sendmsg(credentials)), is
>> there anyway of getting the client PID (or path to binary) using the file
>> descriptor returned by accept() on the server side?
>>
>> Similar to Linux's getsockopt with SO_PEERCRED option.
>>
>
> You want the LOCAL_CREDS socket option from unix(4).
>
> There's also a FreeBSD sample in the UNIX network programming book. Source
> is available from http://unpbook.com/src.html
>
> With the following two changes it seems to work for me:
> unixstrserv02.c: set LOCAL_CREDS
> readcred.c: disable CONTROL_LEN check
>
> $ ./unixstrserv02
> PID of sender = 1001
> real user ID = 1001
> real group ID = 1001
> effective user ID = 1001
> 3 groups: 0 5 920
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Getting PID of socket client

[Stefan Ehmann]

On 09.07.2017 10:03, Johannes Lundberg wrote:

Hi

Without altering the client code (i.e. adding sendmsg(credentials)), is
there anyway of getting the client PID (or path to binary) using the file
descriptor returned by accept() on the server side?

Similar to Linux's getsockopt with SO_PEERCRED option.


You want the LOCAL_CREDS socket option from unix(4).

There's also a FreeBSD sample in the UNIX network programming book. 
Source is available from http://unpbook.com/src.html


With the following two changes it seems to work for me:
unixstrserv02.c: set LOCAL_CREDS
readcred.c: disable CONTROL_LEN check

$ ./unixstrserv02
PID of sender = 1001
real user ID = 1001
real group ID = 1001
effective user ID = 1001
3 groups: 0 5 920
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Getting PID of socket client

[Johannes Lundberg]

follow-up

Seems like at least OpenBSD implemented SO_PEERCRED which returns a struct
sockpeercred.

/* Read using getsockopt() with SOL_SOCKET, SO_PEERCRED */
struct sockpeercred {
uid_t uid; /* effective user id */
gid_t gid; /* effective group id */
pid_t pid;
};

If not anyone is oppose to this or know some other secret API that provides
similar functionality, I can see if I can put together a patch for this
very useful API.



On Sun, Jul 9, 2017 at 10:03 AM, Johannes Lundberg 
wrote:

> Hi
>
> Without altering the client code (i.e. adding sendmsg(credentials)), is
> there anyway of getting the client PID (or path to binary) using the file
> descriptor returned by accept() on the server side?
>
> Similar to Linux's getsockopt with SO_PEERCRED option.
>
> Thanks!
>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Getting PID of socket client

[Johannes Lundberg]

Hi

Without altering the client code (i.e. adding sendmsg(credentials)), is
there anyway of getting the client PID (or path to binary) using the file
descriptor returned by accept() on the server side?

Similar to Linux's getsockopt with SO_PEERCRED option.

Thanks!
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"