From: stsp <stsp2@yandex.ru>
To: Andy Lutomirski <luto@amacapital.net>,
Aleksa Sarai <cyphar@cyphar.com>,
"Serge E. Hallyn" <serge@hallyn.com>
Cc: linux-kernel@vger.kernel.org,
"Stefan Metzmacher" <metze@samba.org>,
"Eric Biederman" <ebiederm@xmission.com>,
"Alexander Viro" <viro@zeniv.linux.org.uk>,
"Andy Lutomirski" <luto@kernel.org>,
"Christian Brauner" <brauner@kernel.org>,
"Jan Kara" <jack@suse.cz>, "Jeff Layton" <jlayton@kernel.org>,
"Chuck Lever" <chuck.lever@oracle.com>,
"Alexander Aring" <alex.aring@gmail.com>,
"David Laight" <David.Laight@aculab.com>,
linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Christian Göttsche" <cgzones@googlemail.com>
Subject: Re: [PATCH v5 0/3] implement OA2_CRED_INHERIT flag for openat2()
Date: Sun, 28 Apr 2024 22:15:53 +0300 [thread overview]
Message-ID: <3e7f3501-d2e5-478e-bc07-bae7730a5503@yandex.ru> (raw)
In-Reply-To: <8e186307-bed2-4b5c-9bc6-bdc70171cc93@yandex.ru>
28.04.2024 20:39, stsp пишет:
> In short: my impl confines the hassle within
> the single process. It can be extended, and
> then the receiver will need to explicitly allow
> adding such fds to his fd table.
> But your idea seems to inherently require
> 2 processes, and there is probably no way
> for the second process to say "ok, I allow
> such sub-tree in my fs scope".
There is probably 1 more detail I had
to make explicit: if my model is extended
to allow SCM_RIGHTS passage by the use
of a new flag on a receiver's side, the kernel
will be able to check that the receiver
currently has the same creds as the sender.
Please note that my model is needed for the
process that does setuid() to a less-privileged
user. He would need to receive the cred fd
_before_ such setuid, he would need to use
the special flag to receive it, and the kernel
will also need to check that he has the same
creds anyway, so no escalation can ever happen.
Only that sequence of events makes the
SCM_RIGHTS passage safe, AFAICT. But if
you don't allow SCM_RIGHTS, as my current
impl does, then you are sure the process
can raise the creds only to his own ones.
Now talking about your sub-tree idea, would
it be possible to check that the process had
initially enough creds to access it w/o inheriting
anything? That part looks important to me,
i.e. the process must not access anything
that he couldn't access before dropping privs.
But I am not sure if your idea even includes
the priv drop.
next prev parent reply other threads:[~2024-04-28 19:16 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-26 13:33 [PATCH v5 0/3] implement OA2_CRED_INHERIT flag for openat2() Stas Sergeev
2024-04-26 13:33 ` [PATCH v5 1/3] fs: reorganize path_openat() Stas Sergeev
2024-04-26 13:33 ` [PATCH v5 2/3] open: add O_CRED_ALLOW flag Stas Sergeev
2024-04-27 2:12 ` kernel test robot
2024-04-26 13:33 ` [PATCH v5 3/3] openat2: add OA2_CRED_INHERIT flag Stas Sergeev
2024-04-28 16:41 ` [PATCH v5 0/3] implement OA2_CRED_INHERIT flag for openat2() Andy Lutomirski
2024-04-28 17:39 ` stsp
2024-04-28 19:15 ` stsp [this message]
2024-04-28 20:19 ` Andy Lutomirski
2024-04-28 21:14 ` stsp
2024-04-28 21:30 ` Andy Lutomirski
2024-04-28 22:12 ` stsp
2024-04-29 1:12 ` stsp
2024-04-29 9:12 ` Christian Brauner
2024-05-06 7:13 ` Aleksa Sarai
2024-05-06 17:29 ` Andy Lutomirski
2024-05-06 17:34 ` Andy Lutomirski
2024-05-06 19:34 ` David Laight
2024-05-06 21:53 ` Andy Lutomirski
2024-05-07 7:42 ` Christian Brauner
2024-05-07 20:38 ` Andy Lutomirski
2024-05-08 7:32 ` Christian Brauner
2024-05-08 17:30 ` Andy Lutomirski
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=3e7f3501-d2e5-478e-bc07-bae7730a5503@yandex.ru \
--to=stsp2@yandex.ru \
--cc=David.Laight@aculab.com \
--cc=alex.aring@gmail.com \
--cc=brauner@kernel.org \
--cc=cgzones@googlemail.com \
--cc=chuck.lever@oracle.com \
--cc=cyphar@cyphar.com \
--cc=ebiederm@xmission.com \
--cc=jack@suse.cz \
--cc=jlayton@kernel.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=luto@kernel.org \
--cc=metze@samba.org \
--cc=pbonzini@redhat.com \
--cc=serge@hallyn.com \
--cc=viro@zeniv.linux.org.uk \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).