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

[Crispin Cowan]

Valdis.Kletnieks@xxxxxx wrote:
> On Tue, 18 Apr 2006 13:13:03 PDT, Crispin Cowan said:
>   
>> This gives the system administrator the ability to force applications to
>> "drop" privs even when the application developer didn't bother, or (as
>> was the case in a Sendmail vulnerability several years ago) the
>> application *tried* to drop privs and got it wrong, so was running as
>> full root anyway.
>>     
> Interestingly enough, the Sendmail bug was a case where it was forced to "drop"
> some privs, and then it didn't have enough privs to drop the rest of the privs.
>
> In other words, it's quite possible to accidentally introduce a vulnerability
> that wasn't exploitable before, by artificially restricting the privs in a way
> the designer didn't expect.  So this is really just handing the sysadmin
> a loaded gun and waiting.
>   
While that is true of the voluntary model of acquiring and dropping
privs, it is not true of AppArmor containment, which will just not give
you the priv if it is not in your policy.

> (Incidentally, both SELinux and presumably AppArmor have the same problem - it
> is really hard to convince yourself that you've identified *all* the access that
> a given program needs.  People keep finding ways to excersize previously untested
> code paths and error handlers, resulting in a game of whack-a-mole as the program
> fails due to a lack of permissions.  This is especially fun to debug when the
> program is already in an error handler... ;)
>   
That is true: both SELinux and AppArmor use a white list within a single
application policy (for the Targeted Policy) leading to this problem.

White lists have the property of being highly secure, but a big pain in
the ass because they *must* be complete, and you shoot yourself in the
foot if they are not. Black lists are the exact dual; relatively
insecure, and relatively easy to use.

AppArmor uses a hybrid white list/black list approach:

    * Per profile, it is white list: when we confine a program, we
      specify every file and POSIX.1e Capability that it can access.
      This includes an inheritance model, so that all of the children
      that it forks are also confined by policy; what they can exec() is
      controlled.
    * System-wide it is black-list: only programs with an explicit
      policy are confined. However, because of the inheritance model,
      confined programs cannot escape by just exec()'ing some program
      that is not normally confined: AppArmor controls what you can
      exec, and thus controls what other policies you can transition to.

AppArmor also aggressively uses wildcards in policy generation, so you
can e.g. grant "/etc/apache2/** r" and "/srv/www/htdocs/** r" to Apache,
and then not have to care whether you fully exercised all of Apache's
configurations and hit all of the web pages.

Crispin
-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com

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