[lkml]   [2006]   [Aug]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 3/7] SLIM main patch
    Quoting Alan Cox (
    > Ar Mer, 2006-08-23 am 13:35 -0700, ysgrifennodd Kylene Jo Hall:
    > > Example: The current process is running at the USER level and writing to
    > > a USER file in /home/user/. The process then attempts to read an
    > > UNTRUSTED file. The current process will become UNTRUSTED and the read
    > > allowed to proceed but first write access to all USER files is revoked
    > > including the ones it has open.
    > Which really doesn't mean anything in many cases because there are many
    > ways to get data out of a file handle once you had it opened for write
    > including sharing via non file handle paths.
    > You also have to deal with existing mmap() mappings and outstanding I/O.

    That she does.

    > So here are some ways to break it
    > SysV shared memory

    standard mmap controls should handle this, right?

    > mmap

    She handles these.

    > or just race it:
    > Open the USER file
    > create a new thread
    > thread #1 create a pipe to a new process ("receiver")
    > thread #1 fill pipe
    > thread #1 issue write of buffer that will hold secret data
    > [blocks after check for rights]
    > thread #2
    > wait for thread #1 to block
    > read secret data into buffer
    > send signal to "receiver"
    > receiver now empties the pipe, the write completes and I get the
    > goodies.

    thread #2 is reading data from a pipe which is at a secret level, so how
    will it exploit that? It can't write it to a lower integrity file...

    > This is why you need a proper implementation of revoke(2) in Linux. You
    > can't really do it any more easily.

    The revoke(2) isn't quite right semantically, because it would revoke
    all users' access, right? Rather, we want one process' rights to all
    files revoked, but other read/writers should still have access.

    Certainly if it were implemented, I'd hope slim could share some of it's

    I did try another version of the revocation code which uses
    change_protection() to remove the write access, then introduced a hook
    on in front of page_mkwrite() to prevent making the page writeable
    again. But I was thinking only of integrity, so actually the secrecy
    concerns would not be addressed.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-08-24 15:35    [W:0.024 / U:9.080 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site