lkml.org 
[lkml]   [2024]   [Apr]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH v5 0/3] implement OA2_CRED_INHERIT flag for openat2()
    From
    29.04.2024 00:30, Andy Lutomirski пишет:
    > On Sun, Apr 28, 2024 at 2:15 PM stsp <stsp2@yandex.ru> wrote:
    >> But isn't that becoming a problem once
    >> you are (maliciously) passed such fds via
    >> exec() or SCM_RIGHTS? You may not know
    >> about them (or about their creds), so you
    >> won't close them. Or?
    > Wait, who's the malicious party?

    Someone who opens an fd with O_CRED_ALLOW
    and passes it to an unsuspecting process. This
    is at least how I understood the Christian Brauner's
    point about "unsuspecting userspace".


    > Anyone who can open a directory has,
    > at the time they do so, permission to do so. If you send that fd to
    > someone via SCM_RIGHTS, all you accomplish is that they now have the
    > fd.

    Normally yes.
    But fd with O_CRED_ALLOW prevents the
    receiver from fully dropping his privs, even
    if he doesn't want to deal with it.

    > In my scenario, the malicious party attacks an *existing* program that
    > opens an fd for purposes that it doesn't think are dangerous. And
    > then it gives the fd *to the malicious program* by whatever means
    > (could be as simple as dropping privs then doing dlopen). Then the
    > malicious program does OA2_INHERIT_CREDS and gets privileges it
    > shouldn't have.

    But what about an inverse scenario?
    Malicious program passes an fd to the
    "unaware" program, putting it under a
    risk. That program probably never cared
    about security, since it doesn't play with
    privs. But suddenly it has privs, passed
    out of nowhere (via exec() for example),
    and someone who hacks it, takes them.

    >>>> My solution was to close such fds on
    >>>> exec and disallowing SCM_RIGHTS passage.
    >>> I don't see what problem this solves.
    >> That the process that received them,
    >> doesn't know they have O_CRED_ALLOW
    >> within. So it won't deduce to close them
    >> in time.
    > Hold on -- what exactly are you talking about? A process does
    > recvmsg() and doesn't trust the party at the other end. Then it
    > doesn't close the received fd. Then it does setuid(getuid()). Then
    > it does dlopen or exec of an untrusted program.
    >
    > Okay, so the program now has a completely unknown fd. This is already
    > part of the thread model. It could be a cred-capturing fd, it could
    > be a device node, it could be a socket, it could be a memfd -- it
    > could be just about anything. How do any of your proposals or my
    > proposals cause an actual new problem here?

    I am not actually sure how widely
    does this spread. I.e. /dev/mem is
    restricted these days, but if you can
    freely pass device nodes around, then
    perhaps the ability to pass an r/o dir fd
    that can suddenly give creds, is probably
    not something new...
    But I really don't like to add to this
    particular set of cases. I don't think
    its safe, I just think its legacy, so while
    it is done that way currently, doesn't
    mean I can do the same thing and
    call it "secure" just because something
    like this was already possible.
    Or is this actually completely safe?
    Does it hurt to have O_CRED_ALLOW
    non-passable?

    >>> This is fundamental to the whole model. If I stick a FAT formatted USB
    >>> drive in the system and mount it, then any process that can find its
    >>> way to the mountpoint can write to it. And if I open a dirfd, any
    >>> process with that dirfd can write it. This is old news and isn't a
    >>> problem.
    >> But IIRC O_DIRECTORY only allows O_RDONLY.
    >> I even re-checked now, and O_DIRECTORY|O_RDWR
    >> gives EISDIR. So is it actually true that
    >> whoever has dir_fd, can write to it?
    > If the filesystem grants that UID permission to write, then it can write.

    Which to me sounds like owning an
    O_DIRECTORY fd only gives you the
    ability to skip the permission checks
    of the outer path components, but not
    the inner ones. So passing it w/o O_CRED_ALLOW
    was quite safe and didn't give you any
    new abilities.


    \
     
     \ /
      Last update: 2024-05-27 18:07    [W:5.963 / U:0.376 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site