RE: Re[2]: SELinux as a desktop / workstation?

RE: Re[2]: SELinux as a desktop / workstation?

[Jonathan Day]

>JP> The reason I'm writing this is, that I'm a bit concerned about security
>JP> issues. Up to now, very little viruses have shaken the linux community,
>JP> but except for selinux and sandbox, there is no thing that prevents code
>JP> running in the user space from doing anything in the user space.
>
>RSBAC (www.rsbac.org; see also ftp.altlinux.ru for Beta-version of "ALT
>Linux Castle" distro).

There are a number of ways to prevent viruses in Linux.

1) Tripwire, et al, are "better" detection tools than a virus scanner, as they don't depend on signatures being present, and therefore detect new viruses as well as old ones.

2) Bastille Linux, OpenWall, LIDS, and other "Linux Hardening Programs" use Linux "capabilities" to disable userland services which aren't necessary.

3) POSIX ACL, Trustees, etc, add "access control lists" to Linux. IMHO, Trustees is a more interesting project, as it goes beyond just trivial ACL lists.

4) Mount your application partitions as "read-only". You don't NEED to have those read/write, except when installing software. Logs, spool-files, etc, all go into /var and the user area is all in /home. Put those two into seperate partitions, which -are- read/write, and you're largely fine.

SELinux would certainly help (in that it would quarantine any infected region), but that is not its primary role.

BTW, since this is a SELinux mailing list, I'll throw in the obligatory plea. Is SELinux holding off for 2.4.5, or will we see a 2.4.4 version?

Jonathan




------------------------------------------------------------
--== Sent via Deja.com ==--
http://www.deja.com/

--
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.

RE: Re[2]: SELinux as a desktop / workstation?

[Stephen Smalley]

>SELinux would certainly help (in that it would quarantine any infected
>region), but that is not its primary role.

I haven't been following this thread closely, but I get the
impression that there may be some misunderstandings on this topic.  Since
SELinux can be used to confine an application to least privilege, it can 
be very effective at limiting the potential damage that can be done either
by a malicious application or by an exploit of a flaw (e.g. a buffer
overflow) in a legitimate application.  SELinux can also be used to
protect the integrity of system software, configuration files, and logs.
And it can be used to protect users from executing untrustworthy software.

>BTW, since this is a SELinux mailing list, I'll throw in the obligatory
>plea. Is SELinux holding off for 2.4.5, or will we see a 2.4.4 version?

We are waiting for 2.4.5.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com





--
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.

RE: Re[2]: SELinux as a desktop / workstation?

[Jesse Pollard]

---------  Received message begins Here  ---------

> 
> >JP> The reason I'm writing this is, that I'm a bit concerned about security
> >JP> issues. Up to now, very little viruses have shaken the linux community,
> >JP> but except for selinux and sandbox, there is no thing that prevents code
> >JP> running in the user space from doing anything in the user space.
> >
> >RSBAC (www.rsbac.org; see also ftp.altlinux.ru for Beta-version of "ALT
> >Linux Castle" distro).
> 
> There are a number of ways to prevent viruses in Linux.

"prevent" is too strong. There is no way prevent given the current hardware
and software structures. The use of "trampoline" code guarantees that in
software. The inability to distinquish between read and execute access
guarantees the hardware vulnerability. Viruses would become (nearly) extinct
with "no-execute data segments", and an execute only text (privileged code).

This leaves only the stack overflow to force an exec (or other system call).
At which point other security measures could become effective.

> 1) Tripwire, et al, are "better" detection tools than a virus scanner, as they don't depend on signatures being present, and therefore detect new viruses as well as old ones.

This detects, but does not prevent.

> 2) Bastille Linux, OpenWall, LIDS, and other "Linux Hardening Programs" use Linux "capabilities" to disable userland services which aren't necessary.

None of which can prevent the virus. They do help limit the spread of
the virus to more than one user (depending on virus entry point).

> 3) POSIX ACL, Trustees, etc, add "access control lists" to Linux. IMHO, Trustees is a more interesting project, as it goes beyond just trivial ACL lists.

only if you are working through the "proper" channels, which a virus would
try to avoid.

> 4) Mount your application partitions as "read-only". You don't NEED to have those read/write, except when installing software. Logs, spool-files, etc, all go into /var and the user area is all in /home. Put those two into seperate partitions, which -are- read/write, and you're largely fine.

And the virus only "remounts". It is good practice, but not an absolute
prevention.

> SELinux would certainly help (in that it would quarantine any infected region), but that is not its primary role.
> BTW, since this is a SELinux mailing list, I'll throw in the obligatory plea. Is SELinux holding off for 2.4.5, or will we see a 2.4.4 version?

It depends on where the virus can attack. If the kernel had no buffer overflow
or programming oversights, it will help. The primary attack point are the
service daemons, which run with some elevated privileges.

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

--
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.

RE: Re[2]: SELinux as a desktop / workstation?

[edm]

> > SELinux would certainly help (in that it would quarantine any infected
region), but that is not its primary role.
>> BTW, since this is a SELinux mailing list, I'll throw in the obligatory
plea. Is SELinux holding off for 2.4.5, or will we see a 2.4.4 version?
>
>It depends on where the virus can attack. If the kernel had no buffer
overflow
>or programming oversights, it will help. The primary attack point are the
>service daemons, which run with some elevated privileges.

Selinx helps in the defense against viruses in the following manner

(1) Propagation: First, let's assume that a program containing a virus has
been introduced into a selinux based system. The program is executed and the
virus decides it wants to propagate. In a properly setup selinux system, the
propagation fails for the following reasons:

  (a) A propagation involves a write to an executable file. The propagation
should fail for the following reasons:

    (i) selinux would stop the propagation because programs (executables)
should (and are normally) intstalled with only read/execute permissions.
This should also be normal unix behavior.

    (ii) In a properly setup selinux system, program executables should have
their own types (which should be different than user/system types). Any
attempt at propagation would cause a policy violation because user/system
domains should not have the ability to write to executables. (Executables
should be loaded in a admin domain, even then only the particular program
type being loaded should the written to.)

Type enforcement under selinux can be viewed as placing programs into a box,
with the box being the accesses allowed for that domain type by the selinux
policy. How restrictive that box is depends upon the the system
implementer/administrator. Note that I've said nothing about the code in
that box, I assume that it is malicious. It is the codes behavior that the
policy is restricting.

(2) Attack. Selinux -->is<-- very effective against buffer overflow attacks,
see my message under that title for further explanation. Other attacks
against the operating system, such as manipulating a system call to attain a
certain result, I would say that it depends. However, the attacker must
figure out a way to neutralize the policy code because simply attaining root
is not good enough.

In short, selinux increases the work needed to break in.

(3) Privileges of service daemons

 "Elevated privileges" in selinux does not mean the same as in a conventual
linux/unix system. each of the service daemons executes in its own domain.
Any exploitation of a sucessful attack against these daemons will, at best,
be able to access what that domain is restricted by the policy to do (as
noted above).

  gene


--
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.

Re[2]: SELinux as a desktop / workstation?

[Maksim Otstavnov]

Hello Jan,

Friday, May 18, 2001, 6:22:43 PM, you wrote:

JP> The reason I'm writing this is, that I'm a bit concerned about security
JP> issues. Up to now, very little viruses have shaken the linux community,
JP> but except for selinux and sandbox, there is no thing that prevents code
JP> running in the user space from doing anything in the user space.

RSBAC (www.rsbac.org; see also ftp.altlinux.ru for Beta-version of "ALT
Linux Castle" distro).

JP> Thank you all for your comments on that,

Not at all. :)

Cheers,

-- 
-- Maksim Otstavnov <maksim@otstavnov.com> http://www.otstavnov.com
-- Computerra weekly,
--  contributing editor



--
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.