sshd Selinux v/s sshd Selinux disabled .......

[Stephen Smalley]

On Thu, 2005-09-15 at 15:14 -0700, Steve G wrote:
> >regarding execute these specific services: sshd, samba, postgres and vsftpd over
> >a system platform Selinux-enabled,
> 
> These are all network daemons. This means they are subject to possibly malicious
> traffic. If there is a hole in any of those apps that lets an intruder exploit
> the app, SE Linux will probably prevent the problem. SE Linux has a basic
> understanding of what the normal syscalls and files or system resources that are
> used by the app. If it spots abnormal behavior, it can stop it.

Note however that whether or not SELinux provides any benefit for a
particular case depends on the particular policy configuration, the
degree to which the application was designed with least privilege in
mind (since the policy has to allow it to do what it needs to do for its
purpose), and the nature of the attack.  For example, under targeted
policy, sshd is unconfined, so SELinux/targeted provides no benefit for
that case, whereas SELinux/strict may provide some benefit.  Further,
while SELinux/strict does put restrictions on what sshd can do, it has
to allow sshd to do what it needs for its purpose, which includes
transitioning to a user shell (although one can limit it to
transitioning to non-privileged user shells and require another
authenticated step like newrole/su to gain privilege as yet another
hurdle).  Decomposing sshd in a way that can be leveraged by SELinux
(i.e. separation into multiple executables for the different stages, and
putting each stage into separate domains) or introducing dynamic context
transitions into sshd to reinforce the existing privilege separation
support would help.

-- 
Stephen Smalley
National Security Agency