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
purpose.
> 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
|>------------------------------------------------------
|| http://www.jmjones.com/
|>------------------------------------------------------
_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Thu May 17 2001 - 06:14:44 PDT