lkml.org 
[lkml]   [2006]   [Apr]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks
    On Wed, Apr 19, 2006 at 02:50:40PM -0400, Valdis.Kletnieks@vt.edu wrote:
    > On Wed, 19 Apr 2006 11:32:56 PDT, Crispin Cowan said:
    >
    > > AppArmor initially validates your access at open time, and there after
    > > you can read&write to it without mediation. AppArmor re-validates your
    > > access if policy is reloaded, you exec() a new program, you get passed
    > > the fd from another process, or you call our change_hat() API.
    > >
    > > So, if the file is unlinked or renamed while you have it open, and
    > > policy says you don't have access to the new name, then:
    > >
    > > * within the same process you get to keep accessing it until
    > > o policy is reloaded by the administrator
    > > o you call the change_hat() API
    > > * in some other process, either a child or some process you passed
    > > an fd to, you don't get to access it because your access gets
    > > revalidated
    >
    > My brain is small, and my eyes glaze over easily... ;)

    Join the club :)

    > What happens for the following sequence:
    >
    > a) Process A does fd = open("/some/protected");
    > b) Somebody then does an unlink("/some/protected");
    > c) A then does a fork/exec, handing the exec'ed process B the open FD
    > as its stdin.

    I just wrote the following which I believe is your test scenario?

    #include <sys/types.h>
    #include <sys/stat.h>
    #include <fcntl.h>
    #include <unistd.h>

    int main()
    {
    int fd, err, pid;

    fd = open("/tmp/protected", O_RDONLY);
    if (fd == -1){
    perror("open") ; return 1;
    }

    err=unlink("/tmp/protected");
    if (err == -1){
    perror("unlink"); close(fd); return 1;
    }

    pid=fork();

    if (pid){
    wait();
    }else{
    close(0);
    dup(fd);

    execl("/bin/cat", "/bin/cat", NULL);
    }

    close(fd);
    }

    d_path reports "/tmp/protected (deleted)" for the dentry in this situation
    when /bin/cat attempts to access it.

    It happens a lot with nscd which likes to open files, unlink them and pass
    them over unix domain sockets. Our old code used to have to remove the
    (deleted) [in a safe manner of course]. With the posted patch to d_path to
    generate pathnames back to the namespace root I took advantage of including
    some control of the appending for unhashed dentries.

    > What name do you use to re-validate B's access to the data described by
    > the inode that open file is referencing?

    Now how you handle what confinement the forked process should have is
    determined when you generate policy. /bin/cat in this situation can run under
    it's own policy (probably not ideal in this situation), inherit the openers
    (probably the ideal choice), or none at all (if you believe it does not
    require confinement).

    > Note that although B can't get any access to the data that A didn't have,
    > it can still be used to bypass security, because B may be able to *copy* that
    > data to an area where A couldn't write (presumably because A is in a confined box).

    I'm not sure how. Perhaps with the above example you can elaborate as
    necessary. Also thanks for posting the question.

    Tony
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-04-20 01:31    [W:4.198 / U:0.464 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site