Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Valdis.Kletnieks@vt.edu]

On Fri, 21 Apr 2006 08:23:51 PDT, Ken Brush said:
> On 4/20/06, Valdis.Kletnieks@vt.edu <Valdis.Kletnieks@vt.edu> wrote:
> > On Wed, 19 Apr 2006 17:19:04 PDT, Crispin Cowan said:
> > > Valdis.Kletnieks@vt.edu wrote:
> > The threat model is that you can take a buggy application, and constrain its
> > access to priv A in a way that causes a code failure that allows you to abuse
> > an unconstrained priv B.
> 
> So you are talking about a 2 prong attack. One in where you somehow
> trick program A to do something that it's allowed to. That then would
> cause an error in program B ? Or cause program B to do something
> wonky.

No, it's a two prong attack against *one* program.  For instance, the Sendmail
bug - the attack A was to cripple its ability to drop privs, which then exposed
it to abuse B of running at a higher priv than it should have.

The crucial point here is that the attacker is trying to gain access to
(for instance) the ability to write to any file, but gets there by crippling
some *other* priv.

Another (totally made up theoretical, hopefully) Sendmail-ish example would be
to artificially constrain it's ability to open port 25 for listening, and then
using a symlink attack to redirect its complaint "I can't open 25" to trash
some file you can't read/write yourself....

The reason that this is such a can-of-worms security wise is that the vast majority
of programs have *not* had sufficient auditing of their error-handling code.
As a result, blindly applying a privilege constraint to clip off some priv A
that the policy writer doesn't think is needed can "load a round in the chamber"
for a clever attacker to abuse.

(Note that this concern applies equally to AppArmor and SELinux and almost any
other constraint-based system.  It's merely more *likely* to bite AppArmor
based systems, because it's marketing itself as "user/sysadmin friendly" - and
thus more likely to attract people trying to secure their system without real
understanding.  You don't get many problems with SELinux down this path,
because most SELinux people already have a mindset that "Even with proper
tools, writing a policy is hard and requires some careful thought/analysis"...)

Attachment: pgppLXqjWLUGM.pgp
Description: PGP signature