[lkml]   [2004]   [Sep]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [ANNOUNCE] Release Digsig 1.3.1: kernel module for run-time authentication of binaries
    * Makan Pourzandi ( wrote:
    > Serge E. Hallyn wrote:
    > > Quoting Chris Wright (
    > >>AFAICT, this means anybody with read access to a file can block all
    > >>writes. This doesn't sound great.
    > >
    > > True.
    > I want to narrow down the discussion, I believe that some people could
    > get confused with the mention of "file" here. AFAICT, the above problem
    > only concerns the shared libraries. Digsig applies only to binaries: in
    > digsig_file_mmap() implementing the file_mmap LSM hook, if the file is
    > not executable there is a return and no verification or any other
    > blocking is done.

    No, it's the mmap PROT check that's the issue.

    > For executables, there is no meaning to load them on read mode, you
    > should have execute permission. if you then load them for execution
    > IMHO, it makes sense to block the writing on that file.

    Thing is, x86 makes no distinction btween r/x so, have you tried mmaping
    with read, then executing (I haven't)? If it works, then you may find
    that there are dumb things out there that do that as well (which you
    wouldn't be able to protect, and become one attack vector). You can make
    a file read-only (no exec bits), and still execute it with Same
    as bash can interpret readonly shell script files. Now, _will_
    mmap PROT_EXEC, so it works for you.

    > For shared libraries, you're right. the problem exists, the shared
    > libraries can be loaded being only readable (even though I remember
    > reading in exec.c:sys_uselib() kernel that the shared libraries
    > must be both readable and executable due to "security reasons", but I'm
    > not an expert and definitely readable is enough to load the shared
    > library but I'll be happy to learn more about this.)
    > > This could be fixed by adding a check at the top of dsi_file_mmap for
    > > file->f_dentry->d_inode->i_mode & MAY_EXEC. Of course then shared
    > > libraries which are installed without execute permissions will cause
    > > apps to break. On my quick test, I couldn't run xterm or vi :)
    > >
    > > Note that blocking writes requires that the file be a valid ELF file,
    > > as this is all that digsig mediates. So I'm not sure which we worry
    > > about more - the fact that all shared libraries have to be installed
    > > with execute permissions (under the proposed solution), or that write
    > My 2 cents, a quick browsing on my machine (fedora core 1) shows that
    > almost all my shared libraries are installed with both execution and
    > read permissions. IMHO, I don't believe then that this should be
    > considered as a major issue.

    This has nothing to do with file permissions aside of read. All you need
    is read permission, then you can mmap(PROT_EXEC) which will kick off the
    check, and do deny_write_access. It's a freeform way to lock writers
    out of any readable file in the system. This is why MAP_EXECUTABLE and
    MAP_DENYWRITE are masked off at syscall entry.

    Linux Security Modules
    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: 2005-03-22 14:06    [W:0.026 / U:13.984 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site