Messages in this thread | | | Date | Wed, 19 Apr 2006 17:19:04 -0700 | From | Crispin Cowan <> | Subject | Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks) |
| |
Valdis.Kletnieks@vt.edu 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |