[lkml]   [2006]   [Apr]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC][PATCH 0/11] security: AppArmor - Overview

I must say that I do not like this code. I created something similar,
ptrace-based, long time ago. It was called, and it
was easy-to-use; but it was also very un-unixy, slow, and gross hack.

Unfortunately AA only fixes the 'slow' part by moving it to the

> AppArmor mediates access to the file system using absolute path names
> with shell-syntax wildcards, so that "/srv/htdocs/** r" grants read
> access to all files in /srv/htdocs. AppArmor mediates access to POSIX.1e

shell-syntax-parser in kernel is not cool.

> AppArmor is strictly monotonic to security: it only restricts privilege,
> never enhancing privilege. So if you add AppArmor to a system, it only
> becomes more secure or stays the same, the security policy will not add

Not true, as sendmail hole showed long time ago. Error paths tend to
be untested, and AA is very capable of unmasking such bugs.

> AppArmor is *not* intended to protect every aspect of the system from
> every other aspect of the system: the intended usage is that only a
> small fraction of all programs on a Linux system will have AppArmor
> profiles. Rather, AppArmor is intended to protect the system against a
> particular threat.

If it is not scalable to whole system, why bother?

If it is only used for small part of system, why not use subterfugue?
Recently patches were proposed to improve ptrace performance a lot...

> Who Needs This?
> -------------------
> AppArmor is a core part of SUSE Linux.

It is part of suse linux, but I'd not call it core part.

Thanks, Sharp!
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-04-22 21:20    [W:0.259 / U:0.716 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site