Re: 2001_05_09 patch against 2.4.4

From: jmjonesat_private
Date: Thu May 17 2001 - 06:13:46 PDT

  • Next message: Jesse Pollard: "Re: 2001_05_09 patch against 2.4.4"

    Um... long moot example follows: READ ONLY IF YOU'RE INTERESTED.
    On 17 May 2001, David Wagner wrote:
    > A good point, but it seems to be irrelevant to the question of whether
    > to allow modules to interpose on read()/write() calls.  The
    > functionality jmjones wants is easily accomplished by checking open()
    > calls, if I am not mistaken.
    Only if the program NEVER normally needs to open the program in the mode
    that may be abused.
    On 17 May 2001, David Wagner ALSO wrote:
    > >Suppose there's a crack that replaces the task's code at some point after 
    > >the file is opened?  Subsequently, a sensitive file (e.g. /etc/passwd) may
    > >be compromised during a read or write from what apparently is a valid 
    > >process.   The capabilities module MAY wish to restrict *certain kinds* 
    > >of read/writes as being "suspicious".
    First of all, my "slip", -capabilities module +security module, please.  
    > Huh??  It is the open("/etc/passwd", .) call that is suspicious,
    True only if the program has no legitimate reason to grab that descriptor.
    > not the read()/write() call.  
    Not necessarily true. Let's take it away from THE QUINTESSENTIAL sensitive
    file and put it in "/usr/etc/sensitive"...
    Program opens "/usr/etc/sensitive" for r+, since it's got a function that 
    allows a field in an existing record to be changed, it's gotta be able to
    seek, read, and write.  During the open lifetime, a crack exploits a
    buffer overflow vulnerability, and decides it wants a trap door.  
    It can either overwrite a known record in the file or add a new
    record to the file, creating a new entry point into the system and 
    flushes the file.  It then cleverly replaces the code it messes up 
    and has a "sleeper" record that it can use subsequently for some 
    > How are you going to decide which read()/write() calls are suspicious?  
    Well, in the above case, the module may allow overwriting certain areas 
    in the file and not others, or may even check the contents of the write
    for prohibitted values, or, even in a coarse case, might just count 
    reads and writes and allow only a certain number before close.  Exactly
    HOW it decides is in the realm of the security module, but unless it can 
    watch reads and writes, it doesn't know what's being done to the file... 
    therefore it has to trust the program after open to do what's expected.
    Trust is a very risky business when dealing with userspace programs.
    > Frankly, I don't understand what you're driving at.  
    No sane program would leave a sensitive file open that long, but 
    programs are not always sane, or even particularly well written.
    The security module may be more than a "guard at the door": it 
    could be a "taskpsychologist" looking for finer grained signs that
    the program has been corrupted, if it can watch reads and writes,
    and decide when to shut it down.
    One module's security philosophy might just not care, another 
    might care very much.  By *not* hooking reads and writes, you
    prohibit something that may be appropriate in some contexts.
    > If there is a good reason to check read()
    > and write() calls, this does not seem to be it.
    Respectfully disagree.  Maybe not *IT*, but a good reason.
    > Anyway, we discussed this issue at length some time ago, and some
    > other policy module writers said they needed the ability to check
    > read() and write() calls.
    Yep.  This is what makes the example above moot, since some have
    already discovered it is needed.  Was just responding to the "reopened"
    question of if they are REALLY necessary.  My vote is "yes", as I can see
    at least ONE reason it may be necessary.
    You May Be Right,
    I May be Crazy...
    J. Melvin Jones
    ||  J. MELVIN JONES            jmjonesat_private 
    ||  Microcomputer Systems Consultant  
    ||  Software Developer
    ||  Web Site Design, Hosting, and Administration
    ||  Network and Systems Administration
    linux-security-module mailing list

    This archive was generated by hypermail 2b30 : Thu May 17 2001 - 06:14:44 PDT