>edm@tycho.ncsc.mil:
>>
>> Actually, selinux provides a very effective defense against the
exploitation
>> of buffer overflows. Here's why:
>>
>> A typical use of the buffer overflow attack is for the attacker to
execute a
>> shell or some other program (such as a compiler as the internet virus
did.)
>> Under selinux, only certain domains are allowed to execute a shell or
>> another program for that matter. If the policy does not allow the domain
>> that the program is executing in to exec a shell or another process (or
fork
>> for that matter), a policy violation occurs and the attack is stopped. In
>> addition, even if the process can execute another program only programs
that
>> have the proper type allowed by the policy can be executed within a
>> particular domain.
>
>True, as far as it goes. The buffer overflow can:
> 1. reload current process memory (it used to be called an "overlay")
> 2. start execution of the reloaded memory (may be a shell or equivalent)
> 3. which resets the stack, frees data space and generally becomes a
> new process via a simulated exec.

Agreed, I assumed that by some means (e.g. no policy violation) you can do the above.

>
>> These restrictions apply to "privileged" (or root) processes as well.
Root
>> under selinux is not like root under linux, it's restricted. All system
>> processes are each setup to execute in their own domain. These domains
have
>> only the privileges that are necessary for its process to execute. For
>> example, if fingerd is attacked using buffer overflow, the policy will
>> prevent it from executing another program. In addition, even if that
>> attacker is able to inject extensive code into the process space, that
code
>> will only be able to access those objects that the policy restricts the
>> fingerd's domain to.
>
>It IS limited to only what the domain permits a process to do directly.
>Indirectly, the process could become a shell anyway.

To be more specific, in certain instances one can inject a program and that program can be a shell. Even then, that "shell" will be confined by the policy.

>
>> However, if the policy allows for that domain type to access /dev/mem (or
>> any file that allows access to system memory) then the system can be
attack.
>> It is important to note, however, that the policy has to allow for a
given
>> domain type to access this and any domain that needs this type of access
>> needs review. -->Under selinux only programs that execute in the klogd
and
>> the xserver domains have this access.<--
>
>In any case, the BEST that can be done is to limit the process into a
>sandbox that only occupies memory. This also means that the original
process
>couldn't do that much that was usefull anyway.

Not necessarily true. After working on selinux policies for quite a while, I can tell you that under selinux these confined processes can do quite a bit (read useful stuff)
and I can still have confidence that if you were able to change the code (by injection) you will still be contained. Type enforcement is quite powerful.

Here's where we diverge. You seem to be defining "penetration" as subverting (or taking over) the currently executing process by injecting data/code. No argument there. If you are worried about that, selinux will not stop this from happening to any program that has an "input" of some sort and is vulnerable to some sort buffer overflow attack. However, I can possibly create a front end (or wrapper) that could protect a program that I feel that may be vulnerable and use the type enforcement to ensure that input always follows that path.

Selinux assumes that the program is already penetrated. So, I "don't care" what code is there because I have still confined its actions.

The below is true, but it doesn't change my statements about what selinux can do. It does mean that one can attempt to attack programs by injecting data. However, under selinux these programs are still confined.

>
>Look at a sample memory layout (this is not exact):
>
>low:
> program text (read only?)
> static data (read write)
> heap (read write)
> stack (read write)
> shared text (read only)
>high:
>
>My arguments are still limited to Intel 32 bit only (and limited there to
>explainations of why "non-exec stack" doesn't stop penetrations).
>
>There is no execute only flag on memory.
>
>Penetration can replace any writable memory. It may reuse the shared text/
>program text for libraries.
>
>The program may remain in the heap and stack space. Any program running
>here can do whatever the domain allows. If the domain "allowed" the initial
>penetration, then there is a channel that can be used to load yet more
>of a program in.
>
>Since /tmp is normally available, there is a LOT of expansion ability if
>the penetrated program can use mmap...
>
>Other hardware controls do change this. Even Intel could be better if the
>memory management hardware had execute capability separate from read; and
>separate from write. Once that is possible then the initial penetration
>would fail.

Actually the i386 archtecture (still) does have this capability when you use its segementation. Too bad current OS's don't use it.

  gene

===snip, snip=====

--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.