From: Crispin Cowan (crispinnovell.com)
Date: Fri Aug 18 2006 - 12:20:26 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Henning Hucke wrote:
> On Thu, 17 Aug 2006, Crispin Cowan wrote:
>
>> [...]
>> Well, no, that is not correct.
>>
> Effectively you blame the german iX magazine to talk rubbish.
>
Sorry, I can't read German, so I wouldn't know.

> The point is: as long as the maintainer doesn't work with the necessary
> care a server might be started in a protected environment if started
> "normaly" and in an unprotected environment if started for instance
> chrooted _despite_ the fact that one and the same binary - for instance
> via a hardlink - is used.
How could that happen?

    * Deliberately: the administrator went to some effort to make a copy
      of the program and run it in an alternate configuration.
    * Maliciously: someone was given a shell and abused it, or they
      escaped from an *unconfined* service and started doing other stuff.

In any of these cases, the person doing the bad thing already has an
unconfined root shell. The game is already over; that they can start
another process without AA confinement is uninteresting compared to the
fact that they can now rootkit the machine.

> The underlaying mechanisms which are used for
> instance by selinux protect _everything_ which uses the protected binary
> might it be a hardlink or a softlink.
>
The difference you highlight is that SELinux provides for a default
policy that applies if no other, more specific policy applies. We have
studied providing a default policy mechanism in AA, but it has this problem:

    * The default policy must be "tight" enough that it at least
      prevents the attacker from breaking AppArmor itself. Otherwise the
      attacker first breaks AA, and then does whatever else they want,
      and the default policy is no more than a speed bump.
    * The default policy must be "loose" enough that administrative
      programs like RPM, YaST, ZMD, etc., and the AA administrative
      software itself, can do their work. Otherwise we would need to
      provide a specific policy for each one of these that is loose
      enough for them to do their jobs.

The intersection of "tight enough" and "loose enough" is the null set. A
speed bump is an unacceptably weak security mechanism. So the only
alternative is to provide specific policies for every administrative
program. So we will not be provisioning a default policy until at least
we can do that.

Instead, we provide the aa-unconfined program. Go run it on your
SUSE10.*, SLES10, or SLED10 machine, and see that it reports a bunch of
programs listening to open network ports, and the AA profiles wrapped
around those programs. If all open network ports lead to AA-confined
programs, then as far as network attackers are concerned, your machine
is "completely" confined, even though you are no where near having
profiled everything on the machine.

If, in the attack Henning is concerned about here, you some how managed
to start a program without an AA profile, then the aa-unconfined scanner
will detect it. If you are very worried about that, then set up
aa-unconfined to run in a cron job and alert you if it sees a problem.
Something like this should do the trick:

aa-unconfined | grep "not confined" | mail rootexample.com

SELinux, in contrast, does have a default policy. This is part of why
SELinux is so difficult to use in practice.

> This smells like AppArmor droped security in favor of ease of use for
> not so firm people. No good deal!
>
That is exactly what AppArmor did:

    * SELinux: Lets build a secure system, and then start trying to make
      it usable. Result: painful-to-use system that is completely
      foreign to UNIX administrators.
    * AppArmor: Lets try to make UNIX/Linux more secure, while still
      being UNIX. Result: transparent UNIX-like mechanisms that help
      make your machine more secure.

People choosing SELinux after considering AppArmor happens approximately
never. People choosing neither SELinux nor AppArmor and instead
remaining "naked" because it is too much bother happens all the time. I
am happy with the decision to emphasize ease of use in AppArmor, as it
means that we can help many, many more people than if we had sacrificed
usability to enhance security.

> SuSE Linux more and more drifts towards "another Windows".
I think it is a bit absurd to claim that SUSE is becoming "another
Windows" every time we add a usability feature. In this case, we have
added a feature that makes Linux much more secure than anything Windows
has. It is also much more secure than a common Red Hat machine, in which
SELinux has been disabled because it was too annoying :)

> In the
> meantime I know a lot of people - amongst them are numerous
> administrators which I personally rate as good or very good ones - who
> already droped SuSE in favor of Debian or comparable distributions.
>
> Mind that.
>
I do mind that. This is why, even though AppArmor is fully integrated
into YaST, that is only a graphical gloss on top of AppArmor. A the
core, AppArmor is command-line driven, making it fast and easy for the
power user to use, works well over slow SSH connections, and is scriptable.

> I personally will install the coming (already released?) SuSE 10.2 on my
> machines and if it will not attract me the installation after this one
> will be debian.
>
> But still: Maybe I'm unfair to SuSE/Novell. If it should be the case
> that I already have the *alternatives* selinux _or_ AppArmor I would
> have to take the above critics. What I want to have is the choice! Give
> other users a tool at hand with which they might secure their machines
> in obscurity as long as you give _me_ the tools at hand to really secure
> the machines under my administration.
>
SELinux and AppArmor cannot share the same machine. Integrating SELinux
into SUSE would require lots and lots of work, and instead we put those
resources towards making AppArmor better. There are many other places
users can get SELinux, so the community gets choice. The number of users
who would actually choose SELinux over AppArmor, after having tried
both, is very small, so we thought it better to just concentrate on
AppArmor.

And there is opensuse.org where you can use the portal to build any RPM
packages for SUSE that you want. If you want SELinux in SUSE, you can
actually do it yourself.

Personally, my experience is that every time I direct an engineer to
work on SELinux, after a while they threaten to quit if I don't change
their assignment :)

Crispin

--
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/
Director of Software Engineering, Novell http://novell.com
     Hack: adroit engineering solution to an unanticipated problem
     Hacker: one who is adroit at pounding round pegs into square holes

--
Check the headers for your unsubscription address
For additional commands, e-mail: suse-security-helpsuse.com
Security-related bug reports go to securitysuse.de, not here

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]