From: firstname.lastname@example.org (Eric W. Biederman) To: Simon Ser <email@example.com> Cc: Linux Kernel Mailing List <firstname.lastname@example.org>, "oleg\@redhat.com" <email@example.com>, "christian\@brauner.io" <firstname.lastname@example.org> Subject: Re: SO_PEERCRED and pidfd Date: Wed, 18 Mar 2020 08:07:29 -0500 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <1Q35NFfgidxjWwXdBPA4EBehI5cyiQ2g47PjP_twMt_AlhcwWIzFK45Dyaw0bKT1KHPsbUAOXbfpvZODuRSd19LVI0tPBPsVblfSYy_YZEgfirstname.lastname@example.org> (Simon Ser's message of "Wed, 18 Mar 2020 10:31:00 +0000") Simon Ser <email@example.com> writes: > On Tuesday, March 17, 2020 7:58 PM, <firstname.lastname@example.org> wrote: > >> Simon Ser email@example.com writes: >> >> > Hi all, >> > I'm a Wayland developer and I've been working on protocol security, >> > which involves identifying the process on the other end of a Unix >> > socket 1. This is already done by e.g. D-Bus via the PID, however >> > this is racy 2. >> > Getting the PID is done via SO_PEERCRED. Would there be interest in >> > adding a way to get a pidfd out of a Unix socket to fix the race? >> >> I think we are passing a struct pid through the socket metadata. >> So it should be technically feasible. >> >> However it does come with some long term mainteance costs. >> >> The big question is what is a pid being used for when being passed. >> Last I looked most of the justifications for using metadata like that >> with unix domain sockets led to patterns of trust that were also >> exploitable. >> >> Looking at the proposale in 1 even if you have race free access >> to /proc/<pid>/exe using pidfds it is possible to change /proc/<pid>/exe >> to be anything you can map so that seems to be an example of a problem. > > /proc/<pid>/exe is a symlink. It doesn't seem like it's possible to > unlink it and re-link it to something else (fails with EPERM). > > Is there a way to do this? prctl(PR_SET_MM_MAP, ...); It is locked down a bit but not enough to trust it in general. Further there are games I can play with ptrace where I can start an executable and control it, so that you think it is the expected executable calling the shots, when in fact it is the process acting as the debugger performing the work. Plus there are the other million and ways known to hijack a setuid executable which also apply to this executable you would trust because of it's exe_link. Even beyond that to have a trusted process it's entire life cycle needs to be trusted, so that you don't have the danger of someone unscrupulous hijacking the process with bad input. >> So it would be very nice to see a use case spelled out where >> the pid reuse race mattered, and that trusting a pid makes sense. > > The use-case is identifying which process is at the other end of the > socket. Once the process is identified, security rules can be applied. > For instance a Wayland compositor might give access to a > screen capture interface if the program is a trusted screen shooter. > > Some want to get the full path to the executable, and read the > /proc/<pid>/exe symlink. Some want to read a special file created at > the root of the process' file system namespace, and access > /proc/<pid>/root. Once we reach the point of having a special file, it is much better to pass that special file. Or possibly something derived from the special file in a zero knowledge proof sort of way, to prove you are a trusted process. Passing a file descriptor as a token the process is the trusted process, is a perfectly fine way to provide proof and unix domains sockets have supported that from day one. I don't see how inspection of a process could make anything better than having the process provide something, and I think it could be even worse. Eric
next prev parent reply other threads:[~2020-03-18 13:09 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-03-17 17:54 Simon Ser 2020-03-17 18:18 ` Christian Brauner 2020-03-18 10:16 ` Simon Ser 2020-03-18 12:21 ` Christian Brauner 2020-03-17 18:58 ` Eric W. Biederman 2020-03-18 10:31 ` Simon Ser 2020-03-18 11:56 ` Christian Brauner 2020-03-18 13:07 ` Eric W. Biederman [this message] 2020-03-18 13:43 ` Christian Brauner
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: SO_PEERCRED and pidfd' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).