lkml.org 
[lkml]   [2018]   [Jul]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH 24/32] vfs: syscall: Add fsopen() to prepare for superblock creation [ver #9]
    Date
    Andy Lutomirski <luto@kernel.org> wrote:

    > > On Jul 11, 2018, at 12:22 AM, David Howells <dhowells@redhat.com> wrote:
    > >
    > > Andy Lutomirski <luto@amacapital.net> wrote:
    > >
    > >>> sfd = fsopen("ext4", FSOPEN_CLOEXEC);
    > >>> write(sfd, "s /dev/sdb1"); // note I'm ignoring write's length arg
    > >>
    > >> Imagine some malicious program passes sfd as stdout to a setuid
    > >> program. That program gets persuaded to write "s /etc/shadow". What
    > >> happens? You’re okay as long as *every single fs* gets it right, but
    > >> that’s asking a lot.
    > >
    > > Do note that you must already have CAP_SYS_ADMIN to be able to call
    > > fsopen().
    >
    > If you're not allowing it already, someone will want user namespace
    > root to be able to use this very, very soon.

    Yeah, I'm sure. And I've been thinking on how to deal with it.

    I think we *have* to open the source files/devices with the creds of whoever
    called fsopen() or fspick() - that way you can't upgrade your privs by passing
    your context fd to a suid program. To enforce this, I think it's simplest for
    fscontext_write() to call override_creds() right after taking the uapi_mutex
    and then call revert_creds() right before dropping the mutex.

    Another thing we might want to look at is to allow a supervisory process to
    examine the context before permitting the create/reconfigure action to
    proceed. It might also be possible to do this through the LSM.

    David


    \
     
     \ /
      Last update: 2018-07-15 22:06    [W:3.517 / U:0.996 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site