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

["Ken Brush" <kbrush@gmail.com>]

On 4/21/06, Valdis.Kletnieks@vt.edu <Valdis.Kletnieks@vt.edu> wrote:
> 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.
>

It's nearly impossible for an access control mechanism to analyze a
program and figure out what it's trying to do.  The whole program
would be constrained with what it would be allowed to do in it's
entirety.  Systems like postfix can be constrained more effectively,
since each individual program would have a tighter policy on what it
can do.

If you can point me to an access control mechanism that could stop
what you describe, I would be very interested in it.

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

This is where you try to cover these mistakes with compiler tools like
Propolice.

> (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"...)

So, because SELinux is harder to configure. When it's exploited no one
is surprised?
Or what is your exact argument?

That sysadmins are not sophisticated enough to properly configure the
MAC systems AppArmor and SELinux effectively? Or that people who use
AppArmor are not likely to put careful thought into the policies that
they use?

-Ken
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/