Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1566987
| From | Andy Lutomirski <luto@amacapital.net> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH 1/2] fs: Check f_cred instead of current's creds in should_remove_suid() |
| Date | 2017-01-25 22:50 +0100 |
| Message-ID | <t3DC2-7dw-17@gated-at.bofh.it> (permalink) |
| References | <t3CZk-6Zx-21@gated-at.bofh.it> <t3CZk-6Zx-31@gated-at.bofh.it> <t3DC1-7dw-1@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Wed, Jan 25, 2017 at 1:43 PM, Ben Hutchings <ben@decadent.org.uk> wrote: > On Wed, 2017-01-25 at 13:06 -0800, Andy Lutomirski wrote: >> If an unprivileged program opens a setgid file for write and passes >> the fd to a privileged program and the privileged program writes to >> it, we currently fail to clear the setgid bit. Fix it by checking >> f_cred instead of current's creds whenever a struct file is >> involved. > [...] > > What if, instead, a privileged program passes the fd to an un > unprivileged program? It sounds like a bad idea to start with, but at > least currently the unprivileged program is going to clear the setgid > bit when it writes. This change would make that behaviour more > dangerous. Hmm. Although, if a privileged program does something like: (sudo -u nobody echo blah) >setuid_program presumably it wanted to make the change. > > Perhaps there should be a capability check on both the current > credentials and file credentials? (I realise that we've considered > file credential checks to be sufficient elsewhere, but those cases > involved virtual files with special semantics, where it's clearer that > a privileged process should not pass them to an unprivileged process.) > I could go either way. What I really want to do is to write a third patch that isn't for -stable that just removes the capable() check entirely. I'm reasonably confident it won't break things for a silly reason: because it's capable() and not ns_capable(), anything it would break would also be broken in an unprivileged container, and I haven't seen any reports of package managers or similar breaking for this reason. --Andy
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH 1/2] fs: Check f_cred instead of current's creds in should_remove_suid() Andy Lutomirski <luto@kernel.org> - 2017-01-25 22:10 +0100
Re: [PATCH 1/2] fs: Check f_cred instead of current's creds in should_remove_suid() Ben Hutchings <ben@decadent.org.uk> - 2017-01-25 22:50 +0100
Re: [PATCH 1/2] fs: Check f_cred instead of current's creds in should_remove_suid() Andy Lutomirski <luto@amacapital.net> - 2017-01-25 22:50 +0100
RE: [PATCH 1/2] fs: Check f_cred instead of current's creds in should_remove_suid() "Frank Filz" <ffilzlnx@mindspring.com> - 2017-01-26 00:40 +0100
Re: [PATCH 1/2] fs: Check f_cred instead of current's creds in should_remove_suid() Kees Cook <keescook@chromium.org> - 2017-01-26 01:20 +0100
csiph-web