From: Florian Weimer <fweimer@redhat.com>
To: Andy Lutomirski <luto@amacapital.net>,
Jim Lieb <jlieb@panasas.com>,
"Eric W. Biederman" <ebiederm@xmission.com>,
LSM List <linux-security-module@vger.kernel.org>,
"Serge E. Hallyn" <serge@canonical.com>,
Kees Cook <keescook@chromium.org>,
Linux FS Devel <linux-fsdevel@vger.kernel.org>,
"Theodore Ts'o" <tytso@mit.edu>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
bfields@redhat.com, Jeff Layton <jlayton@redhat.com>
Subject: Re: Thoughts on credential switching
Date: Thu, 27 Mar 2014 13:46:06 +0100 [thread overview]
Message-ID: <53341D8E.80105@redhat.com> (raw)
In-Reply-To: <CALCETrVyNXYaMWOyWj4gKLWVdzPrSkvv7WTBi2Aa8mYs4NKH9g@mail.gmail.com>
On 03/27/2014 01:23 AM, Andy Lutomirski wrote:
> I propose the following set of new syscalls:
>
> int credfd_create(unsigned int flags): returns a new credfd that
> corresponds to current's creds.
>
> int credfd_activate(int fd, unsigned int flags): Change current's
> creds to match the creds stored in fd. To be clear, this changes both
> the "subjective" and "objective" (aka real_cred and cred) because
> there aren't any real semantics for what happens when userspace code
> runs with real_cred != cred.
This interface does not address the long-term lack of POSIX compliance
in setuid and friends, which are required to be process-global and not
thread-specific (as they are on the kernel side).
glibc works around this by reserving a signal and running set*id on
every thread in a special signal handler. This is just crass, and it is
likely impossible to restore the original process state in case of
partial failure. We really need kernel support to perform the
process-wide switch in an all-or-nothing manner.
--
Florian Weimer / Red Hat Product Security Team
next prev parent reply other threads:[~2014-03-27 12:46 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-27 0:23 Thoughts on credential switching Andy Lutomirski
2014-03-27 0:42 ` Serge Hallyn
2014-03-27 1:01 ` Andy Lutomirski
2014-03-27 15:41 ` Florian Weimer
2014-03-27 16:21 ` Andy Lutomirski
2014-03-27 2:48 ` Jeff Layton
2014-03-27 3:05 ` Andy Lutomirski
2014-03-27 3:25 ` Jeff Layton
2014-03-27 14:08 ` Jeff Layton
2014-03-29 6:43 ` Alex Elsayed
2014-03-30 13:03 ` Theodore Ts'o
2014-03-30 18:56 ` Andy Lutomirski
2014-03-31 11:51 ` Jeff Layton
2014-03-31 18:06 ` Trond Myklebust
2014-03-31 18:12 ` Jeff Layton
2014-03-31 19:26 ` Andy Lutomirski
2014-03-31 20:14 ` Trond Myklebust
2014-03-31 21:25 ` Andy Lutomirski
2014-03-27 12:46 ` Florian Weimer [this message]
2014-03-27 13:02 ` Jeff Layton
2014-03-27 13:06 ` Florian Weimer
2014-03-27 13:33 ` Boaz Harrosh
2014-04-22 11:37 ` Florian Weimer
2014-04-22 12:14 ` Boaz Harrosh
2014-04-22 16:35 ` Jim Lieb
2014-03-27 14:01 ` Jeff Layton
2014-03-27 18:26 ` Jeremy Allison
2014-03-27 18:46 ` Andy Lutomirski
2014-03-27 18:56 ` Jeremy Allison
2014-03-27 19:02 ` Andy Lutomirski
2014-03-27 19:30 ` Jim Lieb
2014-03-27 19:45 ` Andy Lutomirski
2014-03-27 20:47 ` Jim Lieb
2014-03-27 21:19 ` Andy Lutomirski
2014-03-31 10:44 ` One Thousand Gnomes
2014-03-31 16:49 ` Andy Lutomirski
2014-04-01 20:22 ` One Thousand Gnomes
2014-03-31 19:05 ` Jeremy Allison
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 \
--in-reply-to=53341D8E.80105@redhat.com \
--to=fweimer@redhat.com \
--cc=bfields@redhat.com \
--cc=ebiederm@xmission.com \
--cc=jlayton@redhat.com \
--cc=jlieb@panasas.com \
--cc=keescook@chromium.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=serge@canonical.com \
--cc=tytso@mit.edu \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox