AppArmor FAQ

AppArmor FAQ

[John Johansen]

[-- Attachment #1: Type: text/plain, Size: 10606 bytes --]

Here we present our direct responses to the most frequent questions from
the AppArmor from the 2006 post.

Use of Pathnames For Access Control
-----------------------------------

Some people in the security field believe that pathnames are an
inappropriate security mechanism.  This depends on what you are
primarily trying to protect, and the rest follows from that.

Label-based security (exemplified by SELinux, and its predecessors in
MLS systems) attaches security policy to the data. As the data flows
through the system, the label sticks to the data, and so security
policy with respect to this data stays intact. This is a good approach
for ensuring secrecy, the kind of problem that intelligence agencies have.

Pathname-based security (exemplified in AppArmor, and its predecessor
Janus http://www.cs.berkeley.edu/~daw/janus/ and other systems like
Systrace http://www.citi.umich.edu/u/provos/systrace/ ) attach security
policy to the name of the data.

Controlling access to filenames is important because applications
primarily use those names to access the files behind them, and they
depend on getting to the right files. For example, login(1) expects
/etc/passwd to resolve to a valid list of user accounts.  In the
traditional UNIX model, files do have names but not labels, and
applications only operate in terms of those names.  Pathname-based
security puts more emphasis on the integrity of the system, making
secrecy the secondary goal that follows.

Caveat: Both label-based security and pathname-based security can
provide both secrecy and integrity protection, the above discussion is
only about which model makes it easier to provide which kind of security.

We acknowledge that not all objects on a UNIX system are paths, and we
agree that there is value in also protecting non-path resources.
Contrary to popular belief, AppArmor is *not* "Pathnames R Us", but
rather "Use native abstractions to mediate stuff":  when you mediate
something, you should use the native syntax that users normally use to
access the object. This follows the UNIX philosophy of "least surprise"
so that users can understand the specification. Pathnames are the
natural notation for users to understand what file access rights are
being granted in the policy, and so AppArmor uses shell syntax for fully
qualified pathnames, including shell syntax wildcards.

Similarly, AppArmor grants access to POSIX.1e capabilities by name, the
name of the capability. In future work where AppArmor will add network
access control, the notation will resemble IPTables firewall rules. This
is an important part of what makes AppArmor usable: always using the
native abstraction for mediating access.

We also acknowledge that pathname based access control requires a way to
perform pathname matching in the kernel, and this comes at a cost higher
than comparing object labels -- which assumes that all objects in the
system already have the appropriate labels.

However, those concerned with performance should note that AppArmor
overhead is already quite low (single-digit percent slowdown). Security
is rarely performance-neutral, and AppArmor, and SELinux, are no
exception. However, that overhead is small, and can be selectively
avoided by not applying AppArmor to performance-sensitive programs.

It is also easy to overlook the fact that putting all those labels in
place is a pretty expensive operation as well, particularly considering
large file systems. So by providing string matching in the kernel,
AppArmor trades run-time performance to grant reduced administrative work.

It has been suggested that AppArmor's pathname-based syntax could be
compiled into SELinux policy, and this is in fact what the SEEdit
project http://seedit.sourceforge.net/ does. However, any change in
policy requires a complete re-labeling of the file system, and the
policy cannot apply to files that do not yet exist. AppArmor's in-kernel
string matching allows for policy specifying access to files that might
come to exist in the future.

Use Of d_path() For Computing Pathnames
---------------------------------------

We have been criticized for the use of d_path(), for various reasons:

 - heuristic discovery of the vfsmount of a dentry,
 - inability to reliably identify deleted files,
 - inability to detect unreachable paths,
 - ambiguity of paths for chroot processes,
 - file lookup and the access check are not atomic.

Most of these issues are fixable (and fixed in the meantime), while the
non-atomicity is not really an issue.

Because struct vfsmount was not available to LSM hooks for computing
pathnames from (dentry, vfsmount) pairs, the version of AppArmor posted
last year used heuristics for rediscovering the vfsmounts associated
with dentries -- and possibly the wrong ones.  We are now passing the
vfsmount objects through to all LSM hooks that compute pathnames, and so
this heuristic is gone, and now we always use the appropriate vfsmount.

The d_path patch already in the -mm tree allows reliably identifies
deleted files (at least when using the underlying __d_path()), as well
as unreachable paths.

One of the patches in the AppArmor series ensured that the result
returned by __d_path() is consistent even in face of remounts -- the
path returned will always be the name by which the file question was
reachable at the time when d_path was called.

One of the patches in the AppArmor series introduces d_namespace_path(),
based on __d_path(), which gets rid of the chroot ambiguity by computing
paths relative to the namespace root rather than the chroot.

The file lookup and the LSM access check are not atomic with each other
as far as the filesystem namespace is concerned: files may be renamed or
even removed between the lookup and the access check.  It is important
that the lookup happens before the access check, and that the access
check happens before the access, but beyond that, all we care about
security wise is the pathname that the file in question had at the time
of the access check: the file could have been renamed shortly before the
lookup, or shortly thereafter -- this makes no difference because the
only thing we are interested about is the current name of the file.

In case a file is successfully looked up and then deleted before the
access check, it is also obvious how to proceed: the file might as well
have been deleted before the lookup, so we pretend that it was, and
fail the access with errno set to ENOENT.  (This would be fatal for
accesses via open file descriptors -- temporary files are often accessed
after being deleted -- so we make this a special case, and allow
per-file-descriptor accesses to deleted files.)

The "race window" described above in fact is not only between the lookup
and the access check, but is much wider: when a process looks up a file
relative to its current working directory, the lookup is relative to
that directory, and the directory may long since have been renamed.  The
same is true for absolute paths, which are only absolute relative to the
chroot directory.  Still, what we care about is the pathname of the file
at the time of the access check, as above.

The previous version of AppArmor was basing access decisions on the
pathnames of files, even if those files were already deleted.  While it
can be argued that the pathname that can still be recovered from a
deleted file sometimes holds an informational value, it is not obvious
that the name still has value from a security point of view.  We no
longer do that -- instead, we differentiate between file descriptor and
name based accesses.

Working With Name Spaces
------------------------

AppArmor pathname expressions in profiles are relative to the root of
whatever filesystem namespace a process is in. This is secure because
processes can only create new namespaces if they have the CAP_SYS_ADMIN
capability, which confined processes are not supposed to be granted by
their profile because it would allow them to break out of the
confinement, and they can only manipulate their namespace using the
mount system calls, which  confined processes are currently denied as well.

Unconfined processes can still set up different namespaces, and AppArmor
will apply the global policies to each of those namespaces
independently. This prevents AppArmor from confining ClearCase because
of ClearCase's heavy of namespaces, for example.

We are considering how to make AppArmor more flexible to allow some
controlled kinds of mounts, and how to make namespace support more
flexible. One way of improving the namespace support would be to allow
processes to switch between different sets of profiles. The process
setting up a new namespace could then switch to the set of profiles
appropriate for the new namespace as well. (Switching between different
sets of profiles automatically likely will not work -- namespaces do not
have an intrinsic name, and so if the same binary creates multiple
namespaces, there would be no way of telling one from the other.)

Alternate Implementation Strategies
-----------------------------------

It has been observed that computing the pathname after an object has
been looked up is counter-intuitive and racy, and that the pathname
should instead be constructed forwards, during the lookup. While
appealing, this approach breaks for lookups that are relative to the
current working directory (or relative to another open directory like
with openat(2)): in that case, the parent directories of the directory
are never visited (unless the relative path goes all the way up to the
root with ``..'').

All of these cases force the backwards construction of the pathname from
the middle. The pathname up to the root also cannot be cached because
directories along the path could get renamed at any time. Therefore,
since we must be prepared to do backward path construction anyway, we
might as well simplify the mechanism by computing the entire pathname
after looking up the object all of the time.

It has also been suggested that we use a shadow tree, where the module
maintains a shadow mapping from current dentries of interest to the
pathnames for those dentries. However, a very difficult problem with
this approach is that you have two large, complex data structures that
must be kept perfectly synchronized. This particularly becomes a problem
for renames, especially directory renames, which cause a change in the
fully qualified pathname of every file and directory below it,
necessitating large changes to the shadow tree. Our attempts to make
this approach work resulted in worse problems then we had with d_path.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: AppArmor FAQ

[James Morris]

On Mon, 16 Apr 2007, John Johansen wrote:

> Label-based security (exemplified by SELinux, and its predecessors in
> MLS systems) attaches security policy to the data. As the data flows
> through the system, the label sticks to the data, and so security
> policy with respect to this data stays intact. This is a good approach
> for ensuring secrecy, the kind of problem that intelligence agencies have.

Labels are also a good approach for ensuring integrity, which is one of 
the most fundamental aspects of the security model implemented by SELinux.  

Some may infer otherwise from your document.

> Pathname-based security (exemplified in AppArmor, and its predecessor
> Janus http://www.cs.berkeley.edu/~daw/janus/ and other systems like
> Systrace http://www.citi.umich.edu/u/provos/systrace/ ) attach security
> policy to the name of the data.
> 
> Controlling access to filenames is important because applications
> primarily use those names to access the files behind them, and they
> depend on getting to the right files. For example, login(1) expects
> /etc/passwd to resolve to a valid list of user accounts.

And it should, but alas may instead find otherwise due to namespace 
manipulation, object aliasing (e.g. symlinks), application error, 
configuration error, corrupted files, corrupted filesystems, misbehavior 
due to malware infection or various forms user error.

A pathname tells you nothing reliable about the security properties of the 
object its pointing to.  It is simply a mechanism for locating and 
referring to an object.

> In the traditional UNIX model, files do have names but not labels, and 
> applications only operate in terms of those names.

Just to be clear (as the above conflates two distinct notions):  
applications under SELinux still use pathnames for locating and referring 
to files.

SELinux security is enforced within the kernel, and an application which 
does not have permission to access an object will simply receive an error 
using the standard Unix mechanisms already used for DAC.  For example, a 
write(2) might fail with an EACCES error code.

The pathname used by an application to access an object has _nothing_ to 
do with the security attributes of the object.

Traditional Unix security in fact does not primarily depend on pathnames, 
but on DAC ownership and permission attributes stored in the file's inode.

DAC is of course a form of labeled security.

Imagine if you were re-inventing Unix and decided to implement pathname 
security for DAC instead of inode labeling.  What you would have is a more 
generalized version of apparmor, with the DAC attributes of pathnames for 
the entire filesystem stored in a text database with an in-kernel regex 
engine performing path reconstruction and pattern matching on every file 
access.  Sound like a good idea?  I hope not.

How about an analogy: think of kernel objects which are protected by 
locks.  Do you lock the path to the object or do you lock the object 
itself?


> Pathname-based security puts more emphasis on the integrity of the 
> system, making secrecy the secondary goal that follows.

This assertion is being made without any supporting evidence or rationale.  

If you're comparing pathname vs. label security, then it is clear that 
direct object labeling allows the security attributes of the system to be 
specified completely and unambiguously, whereas integrity enforced via 
pathnames alone requires several constraints to be applied to the goals of 
the policy.  So, it seems to me that the opposite of what you say is more 
correct, although it is a fairly oblique argument to start with.

More significant to note is that Type Enforcement was designed 
specifically to address integrity requirements, in response to the 
limitations of the early MLS models which were focused on confidentiality.

See:

"A Practical Alternative to Hierarchical Integrity Policies"
Boebert & Kain, Proceedings of the Eighth National Computer Security 
Conference, 1985.

"Meeting Critical Security Objectives with Security-Enhanced Linux"
http://www.nsa.gov/selinux/papers/ottawa01/index.html

Or pretty much any paper on the design of SELinux or Flask.

Integrity control is a foundational aspect of TE, Flask and SELinux.  

I've never understood why AppArmor presentations tend to so bizarrely 
suggest the opposite.

> Caveat: Both label-based security and pathname-based security can
> provide both secrecy and integrity protection, the above discussion is
> only about which model makes it easier to provide which kind of security.

I don't see how you've established anything in this regard.

> We acknowledge that not all objects on a UNIX system are paths, and we
> agree that there is value in also protecting non-path resources.
> Contrary to popular belief, AppArmor is *not* "Pathnames R Us", but
> rather "Use native abstractions to mediate stuff":  when you mediate
> something, you should use the native syntax that users normally use to
> access the object. This follows the UNIX philosophy of "least surprise"
> so that users can understand the specification. Pathnames are the
> natural notation for users to understand what file access rights are
> being granted in the policy, and so AppArmor uses shell syntax for fully
> qualified pathnames, including shell syntax wildcards.

But, traditional DAC security uses direct labeling of files, just like 
SELinux.  It does not use a separate pathname security file.

So, the traditionalist argument doesn't work here.

And you can still use pathnames under SELinux to locate an object to 
label, just as you do with DAC.  You just don't put a security label on 
the path itself.

> Similarly, AppArmor grants access to POSIX.1e capabilities by name, the
> name of the capability. In future work where AppArmor will add network
> access control, the notation will resemble IPTables firewall rules. This
> is an important part of what makes AppArmor usable: always using the
> native abstraction for mediating access.

Did you know that SELinux has had iptables-based network controls for 
nearly a year?

See http://lwn.net/Articles/184261/

> We also acknowledge that pathname based access control requires a way to
> perform pathname matching in the kernel, and this comes at a cost higher
> than comparing object labels -- which assumes that all objects in the
> system already have the appropriate labels.
> 
> However, those concerned with performance should note that AppArmor
> overhead is already quite low (single-digit percent slowdown). Security
> is rarely performance-neutral, and AppArmor, and SELinux, are no
> exception. However, that overhead is small, and can be selectively
> avoided by not applying AppArmor to performance-sensitive programs.

Keep in mind that if comparing AppArmor and SELinux performance, that 
SELinux is doing a lot more: it's mediating all security-relevant accesses 
being made by the system, not just file accesses.

It would be interesting to try and set up an apples-to-apples test.


> It is also easy to overlook the fact that putting all those labels in
> place is a pretty expensive operation as well, particularly considering
> large file systems. So by providing string matching in the kernel,
> AppArmor trades run-time performance to grant reduced administrative work.

The upfront labeling cost of labeled MAC is not characteristically 
different to that of traditional DAC labeling.  Ideally, an SELinux system 
is installed from scratch with its security labels as well as DAC 
attributes, with the labeling behavior for newly created objects being 
controlled from a well defined policy.  You probably want to avoid getting 
into the situation of needing a TE relabel on a production system in any 
case.



- James
-- 
James Morris
<jmorris@namei.org>

Re: AppArmor FAQ

[David Safford]

On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote:
> On Mon, 16 Apr 2007, John Johansen wrote:
> 
> > Label-based security (exemplified by SELinux, and its predecessors in
> > MLS systems) attaches security policy to the data. As the data flows
> > through the system, the label sticks to the data, and so security
> > policy with respect to this data stays intact. This is a good approach
> > for ensuring secrecy, the kind of problem that intelligence agencies have.
> 
> Labels are also a good approach for ensuring integrity, which is one of 
> the most fundamental aspects of the security model implemented by SELinux.  
> 
> Some may infer otherwise from your document.

In fact, I am not sure how you can provide integrity support without
labels. AppArmor confines a process, but does not effectively confine 
its output files, precisely because the output files are not labeled. 
Other processes are free to access the unlabeled, potentially malicious 
output files without restriction. 

> Imagine if you were re-inventing Unix and decided to implement pathname 
> security for DAC instead of inode labeling.  What you would have is a more 
> generalized version of apparmor, with the DAC attributes of pathnames for 
> the entire filesystem stored in a text database with an in-kernel regex 
> engine performing path reconstruction and pattern matching on every file 
> access.  Sound like a good idea?  I hope not.

Actually, this is pretty much how z/OS/RACF works. Labels and pathnames
for all files are stored in one database. There are advantages and 
disadvantages to this design, but is does work, and does have an EAL4+ 
certification on a Labeled Security Protection Profile.

> And you can still use pathnames under SELinux to locate an object to 
> label, just as you do with DAC.  You just don't put a security label on 
> the path itself.

SELinux _has_ to use pathnames to fix some ugly cases where new files
are created with the wrong label. It uses restorecond to fix the labels
for files such as resolv.conf, mtab, utab, and wtab, when they are 
created. The restorecond policy file is textual, and separate from the 
SELinux labels, which is somewhat inelegant.

RACF provides both labels and canonical paths for all files in one
location. There is no false dichotomy between path based and label 
based security. I don't know how to do this in Linux, with namespaces, 
mounts, and symlinks, but the concept is an interesting counterpoint 
in the discussion.

dave

Re: AppArmor FAQ

[Karl MacMillan]

On Tue, 2007-04-17 at 11:03 -0400, David Safford wrote:
> On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote:
> > On Mon, 16 Apr 2007, John Johansen wrote:
> > 
> Actually, this is pretty much how z/OS/RACF works. Labels and pathnames
> for all files are stored in one database. There are advantages and 
> disadvantages to this design, but is does work, and does have an EAL4+ 
> certification on a Labeled Security Protection Profile.
> 
> > And you can still use pathnames under SELinux to locate an object to 
> > label, just as you do with DAC.  You just don't put a security label on 
> > the path itself.
> 
> SELinux _has_ to use pathnames to fix some ugly cases where new files
> are created with the wrong label. It uses restorecond to fix the labels
> for files such as resolv.conf, mtab, utab, and wtab, when they are 
> created. The restorecond policy file is textual, and separate from the 
> SELinux labels, which is somewhat inelegant.
> 

No - the real fix is to change the applications or to run under a policy
that confines all applications. Most of the problems with resolv.conf,
mtab, etc. stem from admin processes (e.g., editors or shell scripts)
all running under the same unconfined domain.

In some cases applications need modification as only the application has
enough information to determine the correct label. Usually this means
preserving labels from input files or separating the output into
distinct directories so type transitions or label inheritance will work.

restorecond is just a hack not a requirement or a sign that something is
wrong with the model. That is why it is a userspace application and not
integrated into the kernel mechanism.

Karl

Re: AppArmor FAQ

[James Morris]

On Tue, 17 Apr 2007, Andi Kleen wrote:

> You nicely show one of the major disadvantages of the label model vs the path 
> model here: it requires modification of a lot of applications. 

This is incorrect.

Normal applications need zero modification under SELinux.

Some applications which manage security may need to be made SELinux-aware, 
although this can often be done with PAM plugins, which is a standard way 
to do this kind of thing in modern Unix & Linux OSs.

In any case, it has never been unusual for security-critical Unix/Linux 
apps to be aware of extra security frameworks, and conditionally utilize 
things like kerberos, tcpwrappers, SSL, skey etc.

Also, there's nothing inherent in pathname labeling vs. object labeling 
which makes one model require modification of applications more than the 
other.  You're taking one implementation of each and extrapolating to the 
general case, without even taking into consideration that the 
modifications only refer to security-management functions.

Also, in terms of implementation, these security schemes are quite 
different in their coverage and features, so it's an apples vs. oranges 
comparison anyway.


Thanks,



- James
-- 
James Morris
<jmorris@namei.org>

Re: AppArmor FAQ

[Andi Kleen]

Karl MacMillan <kmacmill@redhat.com> writes:
 
> No - the real fix is to change the applications or to run under a policy
> that confines all applications. Most of the problems with resolv.conf,
> mtab, etc. stem from admin processes (e.g., editors or shell scripts)
> all running under the same unconfined domain.
> 
> In some cases applications need modification as only the application has
> enough information to determine the correct label. Usually this means
> preserving labels from input files or separating the output into
> distinct directories so type transitions or label inheritance will work.
> 
> restorecond is just a hack not a requirement or a sign that something is
> wrong with the model. That is why it is a userspace application and not
> integrated into the kernel mechanism.

You nicely show one of the major disadvantages of the label model vs the path 
model here: it requires modification of a lot of applications. 

Maybe John can borrow your statement for new versions of his FAQ @)

-Andi

Re: AppArmor FAQ

[Andi Kleen]

On Tue, Apr 17, 2007 at 01:47:39PM -0400, James Morris wrote:
> Normal applications need zero modification under SELinux.
> 
> Some applications which manage security may need to be made SELinux-aware, 

Anything that can touch /etc/resolv.conf? That's potentially a lot of binaries
if you consider anything scripts could do with it.

> although this can often be done with PAM plugins, which is a standard way 
> to do this kind of thing in modern Unix & Linux OSs.

PAM plugins in vi and emacs? Scary idea.

And what do you do if someone decides to use OpenOffice to edit their
/etc/resolv.conf? For a lot of people that's the only text editor 
they know.

-Andi

Re: AppArmor FAQ

[Casey Schaufler]

--- Andi Kleen <andi@firstfloor.org> wrote:

> On Tue, Apr 17, 2007 at 01:47:39PM -0400, James Morris wrote:
> > Normal applications need zero modification under SELinux.
> > 
> > Some applications which manage security may need to be made SELinux-aware, 
> 
> Anything that can touch /etc/resolv.conf? That's potentially a lot of
> binaries
> if you consider anything scripts could do with it.

Well, no, you don't have to modify everything that might modify resolv.conf.
You do have to define your policy so that the set of things that might
modify resolv.conf is limited to the set of things that are appropriate.

You also need to note that SELinux has a notion of privilege that is
different from what is traditional. The ability to modify resolv.conf
is determined by the domain containing it and the relationship of the
domain containing the application to that domain, modified by any
domain transitions that may have occured to the process prior to or
during the attempted access.

> > although this can often be done with PAM plugins, which is a standard way 
> > to do this kind of thing in modern Unix & Linux OSs.
> 
> PAM plugins in vi and emacs? Scary idea.
> 
> And what do you do if someone decides to use OpenOffice to edit their
> /etc/resolv.conf? For a lot of people that's the only text editor 
> they know.

For SELinux to be effective it has to have a complete policy definition.
This would prevent the OpenOffice access (unless OpenOffice is in the
modify_resolv_conf_t domain) above.

This, by the way, is a fundimental advantage of a path scheme over a
label scheme in that label schemes require every object be labeled
(it's Section 3.1.1.3 of the TCSEC if you want to look it up) while a
path scheme (in the absences of a published requirement) only requires
those names it cares about. SELinux in the absence of a correct and
complete policy could be considered dangerous.


Casey Schaufler
casey@schaufler-ca.com

Re: AppArmor FAQ

[James Morris]

On Tue, 17 Apr 2007, Casey Schaufler wrote:

> those names it cares about. SELinux in the absence of a correct and
> complete policy could be considered dangerous.

It should be noted that SELinux is only recommended as an addition to DAC, 
not a replacement, so that it can only further restrict existing access 
control.


- James
-- 
James Morris
<jmorris@namei.org>

Re: AppArmor FAQ

[Andi Kleen]

> For SELinux to be effective it has to have a complete policy definition.
> This would prevent the OpenOffice access (unless OpenOffice is in the
> modify_resolv_conf_t domain) above.

This would mean no fully functional root user anymore. My understanding 
is rather that at least in the Fedora default setup individual applications
are confined with targetted policy and root left alone because normal system 
administrators get very unhappy when root becomes powerless.

I was merely pointing out that in this setup path or namespace based access 
control are much easier to fit in than label based access because they normally 
don't require changing applications. John's original document also
listed some other advantages that I don't need to repeat.

In "i don't care if it looks like Unix anymore" security setups like
you're describing that's undoubtedly different and labels might indeed
work because you forbid just anybody changing them easily. If that makes
the users happy is a different question though. I suppose it will
keep security consultants employed at least @)

Arguably the preserving label issue is not unique to SELinux but 
also applies to ACLs and other possible uses of EAs, but then people normally 
don't need to set any ACLs on /etc/resolv.conf.

I personally don't like either too much. Path based access control
is somewhat hackish and ugly and slow in the current implementation, 
but I haven't seen an similarly easy to configure solution yet.

plan9 like limited namespaces for individual processes initially seem 
like a nice alternative, but in practice they're also too hard to use and 
suffer from many of the problems the EA label approach has.

But easy to use security is probably better than complicated security
because normal people will more likely use it.

-Andi

Re: AppArmor FAQ

[Karl MacMillan]

On Tue, 2007-04-17 at 23:16 +0200, Andi Kleen wrote:
> > For SELinux to be effective it has to have a complete policy definition.
> > This would prevent the OpenOffice access (unless OpenOffice is in the
> > modify_resolv_conf_t domain) above.
> 
> This would mean no fully functional root user anymore. My understanding 
> is rather that at least in the Fedora default setup individual applications
> are confined with targetted policy and root left alone because normal system 
> administrators get very unhappy when root becomes powerless.
> 
> I was merely pointing out that in this setup path or namespace based access 
> control are much easier to fit in than label based access because they normally 
> don't require changing applications. John's original document also
> listed some other advantages that I don't need to repeat.
> 

Again - this is incorrect. The vast majority of applications are not
modified to be SELinux aware - only a small handful of security aware
applications are modified. Most labeling is handled transparently by the
policy and more could be handled by the policy if it covered all
processes.

> In "i don't care if it looks like Unix anymore" security setups like
> you're describing that's undoubtedly different and labels might indeed
> work because you forbid just anybody changing them easily. If that makes
> the users happy is a different question though. I suppose it will
> keep security consultants employed at least @)
> 

Unix security is often convenient but it is clear that it is
insufficient.

> Arguably the preserving label issue is not unique to SELinux but 
> also applies to ACLs and other possible uses of EAs, but then people normally 
> don't need to set any ACLs on /etc/resolv.conf.
> 

It also applies to ordinary Unix DAC. Many applications preserve mode
and / or owner bits on files. Think about an editor saves to a temporary
file and renames rather than directly writing the original file name.
For this to work correctly the editor must explicitly preserve DAC mode
bits in addition to ACLs or an SELinux label.

The advantage of using a labeling scheme is, of course, that the data is
always protected even in the temporary file (which might be left around
if the editor crashes) while this is not true for path based security.
Would DAC restrictions be acceptable if renaming a file suddenly allowed
everyone to access that file?

> I personally don't like either too much. Path based access control
> is somewhat hackish and ugly and slow in the current implementation, 
> but I haven't seen an similarly easy to configure solution yet.
> 
> plan9 like limited namespaces for individual processes initially seem 
> like a nice alternative, but in practice they're also too hard to use and 
> suffer from many of the problems the EA label approach has.
> 
> But easy to use security is probably better than complicated security
> because normal people will more likely use it.
> 

I don't think that the ease-of-use issue is clear cut. The hard part of
understanding both SELinux policies and AppArmor profiles is
understanding what access should be allowed. For example, most admins
are hard pressed to know whether OpenOffice should be allowed to
access /dev/random or the security implications of /dev/random
vs /dev/urandom. Whether the access is allowed with the SELinux or
AppArmor language seems like a small issue in comparison. Given that I
think it is better to choose the solution that is complete and capable
of meeting the most security concerns.

I'd also argue that the typical interface presented to admins (which
doesn't involve writing new policies) is easier for SELinux than with
AppArmor. Most admins do fine with relabeling, changing booleans, and
running audit2allow, which is all that is needed to solve the majority
of SELinux issues.

Karl

Re: AppArmor FAQ

[Karl MacMillan]

On Tue, 2007-04-17 at 13:19 -0700, Casey Schaufler wrote:
> --- Andi Kleen <andi@firstfloor.org> wrote:
> > > although this can often be done with PAM plugins, which is a standard way 
> > > to do this kind of thing in modern Unix & Linux OSs.
> > 
> > PAM plugins in vi and emacs? Scary idea.
> > 
> > And what do you do if someone decides to use OpenOffice to edit their
> > /etc/resolv.conf? For a lot of people that's the only text editor 
> > they know.
> 
> For SELinux to be effective it has to have a complete policy definition.
> This would prevent the OpenOffice access (unless OpenOffice is in the
> modify_resolv_conf_t domain) above.
> 
> This, by the way, is a fundimental advantage of a path scheme over a
> label scheme in that label schemes require every object be labeled
> (it's Section 3.1.1.3 of the TCSEC if you want to look it up) while a
> path scheme (in the absences of a published requirement) only requires
> those names it cares about. SELinux in the absence of a correct and
> complete policy could be considered dangerous.
> 

This is wildly untrue (as I believe you know Casey). The effectiveness
of SELinux is certainly diminished by not confining all applications,
but that in no way makes it dangerous. It simply means that certain
aspects of the security are no longer guaranteed by the policy but
instead rely on application correctness. SELinux still offers useful
protections against a variety security threats in a targeted
configuration.

This is in contrast to a security mechanism that is path based and
doesn't control all accesses which can make _no_ guarantees about any
security goals. 

Karl

Re: AppArmor FAQ

[David Wagner]

Karl MacMillan  wrote:
>I don't think that the ease-of-use issue is clear cut. The hard part of
>understanding both SELinux policies and AppArmor profiles is
>understanding what access should be allowed. [...]
>Whether the access is allowed with the SELinux or
>AppArmor language seems like a small issue in comparison. Given that I
>think it is better to choose the solution that is complete and capable
>of meeting the most security concerns.

I have a different reaction.  Given that the ease of use vs
completeness issues are not completely understood, I would think
it would make more sense to include both in the kernel.  Wasn't that
the whole point of the LSM interface, to let competing approaches
bloom and compete on their merits?

I have to say that I'm not convinced the difference in policy
languages is a small issue.  I find the SELinux policy language
and policy files more or less inscrutable.  In comparison, from
the AppArmor FAQ, I can imagine that I might be able to understand
enough to hack AppArmor policies after 5 minutes of reading a
man page.  Whether I'm likely to know what the policy ought to be
is indeed a tough question, but I can imagine that AppArmor might
be more usable than SELinux.  Even if SELinux is more "complete"
than AppArmor, I might still prefer ease of use over completeness
and understandability.

And I have to say that the ability to form a mental model of how
the system works and understand more or less what it is doing may
be useful.  I find debugging SELinux problems a bear: I often just
end up disabling entire SELinux policies, or turning off SELinux,
because I can't understand what it's doing.  In comparison, it's
plausible that it might be easier for sysadmins to understand what
AppArmor is doing, since they don't have to understand labelling and
hard-to-read policy files.  And the increase in understandability
might potentially outweigh the "completeness" issue, in some cases.
Ultimately, easier to use and easier to understand tools might
better solve security overall, because they are more likely to be
used and to be used correctly.

Bottom line: I think the comparison regarding ease of use is a
bit speculative at this point, but I think there is sufficient
reason for thinking that AppArmor might be a useful tool in some
deployment environments.

>I'd also argue that the typical interface presented to admins (which
>doesn't involve writing new policies) is easier for SELinux than with
>AppArmor. Most admins do fine with relabeling, changing booleans, and
>running audit2allow, which is all that is needed to solve the majority
>of SELinux issues.

Heh.  I had to chuckle at that one: it is pretty far removed from
my own personal experience.

Re: AppArmor FAQ

[Karl MacMillan]

On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote:
> On Mon, 16 Apr 2007, John Johansen wrote:
> 
> > Label-based security (exemplified by SELinux, and its predecessors in
> > MLS systems) attaches security policy to the data. As the data flows
> > through the system, the label sticks to the data, and so security
> > policy with respect to this data stays intact. This is a good approach
> > for ensuring secrecy, the kind of problem that intelligence agencies have.
> 
> Labels are also a good approach for ensuring integrity, which is one of 
> the most fundamental aspects of the security model implemented by SELinux.  
> 
> Some may infer otherwise from your document.
> 

Not only that, the implication that secrecy is only useful to
intelligence agencies is pretty funny. Personally, I think that
protecting the confidentiality of my data is important (and my bank and
health care providers protecting the data they have about me). Type
Enforcement was specifically designed to be able to address integrity
_and_ confidentiality in a way acceptable to commercial organizations.

Karl

Re: AppArmor FAQ

[Alan Cox]

> But easy to use security is probably better than complicated security
> because normal people will more likely use it.

Easy to use security is only better if it *works*, and preferably its
excessively secure. Ineffective security is actually worse than no
security.

Real world examples include people using RFID badges thinking they are
secure so removing the use of the conventional key in door lock and
people using WEP wireless security so running no encryption or other
security on their wireless. Several of whom if statements are to believed
then found themselves being sued by the music industry because their IP
was used for file sharing.

Bad security is dangerous, really dangerous.


I'm not sure if AppArmor can be made good security for the general case,
but it is a model that works in the limited http environment
(eg .htaccess) and is something people can play with and hack on and may
be possible to configure to be very secure.

Alan

Re: AppArmor FAQ

[Andi Kleen]

> The vast majority of applications are not
> modified to be SELinux aware - only a small handful of security aware
> applications are modified. 

All applications that can edit /etc/resolv.conf? That's nearly 
everything. You yourself gave the example; I'm not making anything up.

-Andi (sensing a loop in the thread -- things that already have been
discussed come back from the dead.)

P.S.: If you want to loop further please drop me from cc.

Re: AppArmor FAQ

[Alan Cox]

> I have a different reaction.  Given that the ease of use vs
> completeness issues are not completely understood, I would think
> it would make more sense to include both in the kernel.  Wasn't that
> the whole point of the LSM interface, to let competing approaches
> bloom and compete on their merits?

Yes and that was the decision reached last kernel summit.

The remaining problem is to get AppArmor into a state ready for merging,
which hopefully this review series is doing.

Re: AppArmor FAQ

[Karl MacMillan]

On Tue, 2007-04-17 at 20:10 +0200, Andi Kleen wrote:
> On Tue, Apr 17, 2007 at 01:47:39PM -0400, James Morris wrote:
> > Normal applications need zero modification under SELinux.
> > 
> > Some applications which manage security may need to be made SELinux-aware, 
> 
> Anything that can touch /etc/resolv.conf? That's potentially a lot of binaries
> if you consider anything scripts could do with it.
> 

Certainly not - most things are handled by policy. I don't think that
any applications shipped with Fedora are modified to handle resolv.conf.
They are either confined and policy takes care of it or, in the case of
things like vi, they are generically modified to preserve labels (and
that change is partially to accommodate the targeted policy). Any
application that preserves DAC mode bits should likely also preserve
ACLs and SELinux labels (I guess they should potentially just preserve
all xattrs - not certain).

> > although this can often be done with PAM plugins, which is a standard way 
> > to do this kind of thing in modern Unix & Linux OSs.
> 
> PAM plugins in vi and emacs? Scary idea.
> 

Err, no. I don't think that is what James was suggesting.

> And what do you do if someone decides to use OpenOffice to edit their
> /etc/resolv.conf? For a lot of people that's the only text editor 
> they know.
> 

Yeah right, I'm certain there are a lot of users (even clueless ones)
that use OO for files in /etc. I assume that line wrapping alone would
make this impossible and running a huge X application as root is
obviously not the best idea. Actually, it seems unlikely that a clueless
user would know how to run OO as root.

Anyway, general concerns aside, for a targeted system this would likely
just work depending on how OO saves files or whether it preserves
labels.

It would also be possible to create a small policy that defined a domain
for OO that would allow editing resolv.conf. If you went that route the
policy could set the label correctly. This is actually one of the major
advantages of SELinux. You can create multiple domains for the same app
that allow different actions depending on the circumstances.

Karl

Re: AppArmor FAQ

[Karl MacMillan]

On Wed, 2007-04-18 at 00:12 +0200, Andi Kleen wrote:
> > The vast majority of applications are not
> > modified to be SELinux aware - only a small handful of security aware
> > applications are modified. 
> 
> All applications that can edit /etc/resolv.conf? That's nearly 
> everything. You yourself gave the example; I'm not making anything up.
> 

No - read my other mail on this subject.

> 
> -Andi (sensing a loop in the thread -- things that already have been
> discussed come back from the dead.)
> 
> P.S.: If you want to loop further please drop me from cc.
> 

I might be wrong, but I think that the loop is partially coming from you
not understanding how policy normally handles labeling. There is some
information at http://www.nsa.gov/selinux/papers/slinux/node16.html.

Karl

Re: AppArmor FAQ

[Crispin Cowan]

Karl MacMillan wrote:
> On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote:
>   
>> On Mon, 16 Apr 2007, John Johansen wrote:
>>     
>>> Label-based security (exemplified by SELinux, and its predecessors in
>>> MLS systems) attaches security policy to the data. As the data flows
>>> through the system, the label sticks to the data, and so security
>>> policy with respect to this data stays intact. This is a good approach
>>> for ensuring secrecy, the kind of problem that intelligence agencies have.
>>>       
>> Labels are also a good approach for ensuring integrity, which is one of 
>> the most fundamental aspects of the security model implemented by SELinux.  
>>
>> Some may infer otherwise from your document.
>>     
> Not only that, the implication that secrecy is only useful to
> intelligence agencies is pretty funny.
That was not the claim. Rather, that intelligence agencies have a very
strong need for privacy, and will go to greater lengths to get it,
including using MLS systems. I contend that while most organizations
want privacy, they don't want it so badly that they will put up with
MLS, and so are looking for a more tolerable form of security.

This is relevant here because information flow is the main advantage of
labels over pathnames for access control. AppArmor does not attempt to
manage information flow, allowing it to use pathnames to achieve ease of
use. If you want information flow control, then by all means use a
label-based system.

Crispin

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

Re: AppArmor FAQ

[Crispin Cowan]

David Safford wrote:
> On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote:
>   
>> On Mon, 16 Apr 2007, John Johansen wrote:
>>     
>>> Label-based security (exemplified by SELinux, and its predecessors in
>>> MLS systems) attaches security policy to the data. As the data flows
>>> through the system, the label sticks to the data, and so security
>>> policy with respect to this data stays intact. This is a good approach
>>> for ensuring secrecy, the kind of problem that intelligence agencies have.
>>>       
>> Labels are also a good approach for ensuring integrity, which is one of 
>> the most fundamental aspects of the security model implemented by SELinux.  
>>
>> Some may infer otherwise from your document.
>>     
> In fact, I am not sure how you can provide integrity support without
> labels. AppArmor confines a process, but does not effectively confine 
> its output files, precisely because the output files are not labeled. 
> Other processes are free to access the unlabeled, potentially malicious 
> output files without restriction. 
>   
That depends on what you mean by "integrity." It is true that AppArmor
does not directly manage information flow. AppArmor assumes that if you
granted write permission to /etc/resolv.conf, that you meant to do that.
Whether any other process is permitted to access /etc/resolv.conf is
determined by those other process's respective profiles.

What AppArmor provides is a way for administrators to confine software
that they have to run but do not trust. The use of pathnames means that
the administrator can understand the exact meaning of the security
policy, without having to do a complete labeling of the file system. The
flip side of not managing information flow is that each profile is
independent of every other profile.

The meaning of a file is how other processes interpret it. Until then,
/etc/resolv.conf is just a quaint bag of bits. What makes it special is
that it is what each process gets when they open the well-known
"/etc/resolv.conf". Which is why it is useful to guard which processes
can read or write to /etc/resolv.conf; the name is what makes its
content special, not the other way around.

Crispin

-- 
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin/
Director of Software Engineering   http://novell.com
"You cannot say anything that is both simple and complete."--Crispin on Goedel

Re: AppArmor FAQ

[Casey Schaufler]

--- Karl MacMillan <kmacmill@redhat.com> wrote:

> On Tue, 2007-04-17 at 13:19 -0700, Casey Schaufler wrote:
> > --- Andi Kleen <andi@firstfloor.org> wrote:
> > > > although this can often be done with PAM plugins, which is a standard
> way 
> > > > to do this kind of thing in modern Unix & Linux OSs.
> > > 
> > > PAM plugins in vi and emacs? Scary idea.
> > > 
> > > And what do you do if someone decides to use OpenOffice to edit their
> > > /etc/resolv.conf? For a lot of people that's the only text editor 
> > > they know.
> > 
> > For SELinux to be effective it has to have a complete policy definition.
> > This would prevent the OpenOffice access (unless OpenOffice is in the
> > modify_resolv_conf_t domain) above.
> > 
> > This, by the way, is a fundimental advantage of a path scheme over a
> > label scheme in that label schemes require every object be labeled
> > (it's Section 3.1.1.3 of the TCSEC if you want to look it up) while a
> > path scheme (in the absences of a published requirement) only requires
> > those names it cares about. SELinux in the absence of a correct and
> > complete policy could be considered dangerous.
> > 
> 
> This is wildly untrue (as I believe you know Casey).

Is it? In an environment with automatic domain transitions and
socket based administrative interfaces I can easily imagine how
an incorrect or incomplete policy definition (or even one containing
an ill advised regular expression in a pathname) could result in
a user being able to get inappropriate service from an application.
Maybe I am being silly. I am part of the generation that treats
the setuid bit gingerly, and one of the people who worked to see that
the POSIX capability mechanism was appropriately careful. The notion
of applications flipping their security contexts about based on
externally specified rules in an environment where communications
with potentially privileged processes are covered by another set
of those rules does not inspire confidence. I think that those rules
had better be very carefully defined for them to be worthy of trust.

> The effectiveness
> of SELinux is certainly diminished by not confining all applications,
> but that in no way makes it dangerous. It simply means that certain
> aspects of the security are no longer guaranteed by the policy but
> instead rely on application correctness. SELinux still offers useful
> protections against a variety security threats in a targeted
> configuration.

OK, if it make you feel secure, that's fine. It doesn't do anything
for me.

> This is in contrast to a security mechanism that is path based and
> doesn't control all accesses which can make _no_ guarantees about any
> security goals. 

But ... in a targeted policy SELinux isn't controlling all accesses, either.
Well, there's really no point it making further arguements. I don't
expect to get through where I've failed before. And SELinux is still the
best type enforcement scheme available, so if you like that sort of thing
it's a fine choice. I still don't think that the arguments against path
based access are particularly compelling.


Casey Schaufler
casey@schaufler-ca.com

Re: AppArmor FAQ

[Karl MacMillan]

On Tue, 2007-04-17 at 15:55 -0700, Crispin Cowan wrote:
> Karl MacMillan wrote:
> > On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote:
> >   
> >> On Mon, 16 Apr 2007, John Johansen wrote:
> >>     
> >>> Label-based security (exemplified by SELinux, and its predecessors in
> >>> MLS systems) attaches security policy to the data. As the data flows
> >>> through the system, the label sticks to the data, and so security
> >>> policy with respect to this data stays intact. This is a good approach
> >>> for ensuring secrecy, the kind of problem that intelligence agencies have.
> >>>       
> >> Labels are also a good approach for ensuring integrity, which is one of 
> >> the most fundamental aspects of the security model implemented by SELinux.  
> >>
> >> Some may infer otherwise from your document.
> >>     
> > Not only that, the implication that secrecy is only useful to
> > intelligence agencies is pretty funny.
> That was not the claim.

It might not have been the claim, but I certainly think it was the
implication.

>  Rather, that intelligence agencies have a very
> strong need for privacy, and will go to greater lengths to get it,
> including using MLS systems. I contend that while most organizations
> want privacy, they don't want it so badly that they will put up with
> MLS, and so are looking for a more tolerable form of security.
> 

Definitely - which is why SELinux is primarily about type enforcement.

> This is relevant here because information flow is the main advantage of
> labels over pathnames for access control.

I would say that controlling information flow is _one_ of the main
advantages of labels. There are others.

>  AppArmor does not attempt to
> manage information flow, allowing it to use pathnames to achieve ease of
> use. If you want information flow control, then by all means use a
> label-based system.
> 

You're trying to force a false choice between "ease of use" and
"information flow control". These AppArmor / SELinux debates are
irritating enough without these kinds of misleading rhetorical
techniques.

Karl

Re: AppArmor FAQ

[Karl MacMillan]

On Tue, 2007-04-17 at 16:09 -0700, Crispin Cowan wrote:
> David Safford wrote:
> > On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote:
> >   

<snip>

> 
> The meaning of a file is how other processes interpret it. Until then,
> /etc/resolv.conf is just a quaint bag of bits. What makes it special is
> that it is what each process gets when they open the well-known
> "/etc/resolv.conf". Which is why it is useful to guard which processes
> can read or write to /etc/resolv.conf; the name is what makes its
> content special, not the other way around.
> 

This is not correct. My private ssh keys need to be protected regardless
of the file name - it is the "bag of bits" that make it important not
the name. Similarly, you protect the integrity of the applications that
need name resolution by ensuring that the data that they read is high
integrity. You do that by controlling data not the file name used to
access the data. That is James point - a comprehensive mechanism like
SELinux allows you to comprehensively protect the integrity of data.

Karl

> Crispin
> 

Re: AppArmor FAQ

[David Wagner]

Karl MacMillan  wrote:
>My private ssh keys need to be protected regardless
>of the file name - it is the "bag of bits" that make it important not
>the name.

I think you picked a bad example.  That's a confidentiality policy.
AppArmor can't make any guarantees about confidentiality.  Neither can
SELinux.  If you give a malicious app the power to read your private ssh
key, it's game over, dude.  (Covert channels, wall banging, and all that.)
So don't do that.

>Similarly, you protect the integrity of the applications that
>need name resolution by ensuring that the data that they read is high
>integrity. You do that by controlling data not the file name used to
>access the data. That is James point - a comprehensive mechanism like
>SELinux allows you to comprehensively protect the integrity of data.

I think this argument just misses the point.  What you want isn't what
AppArmor does.  Fine.  Nobody is forcing you to use AppArmor.  But that
doesn't mean AppArmor is useless.  There may be people who want what
AppArmor has to provide.

It sounds like you want a comprehensive information flow control system.
That's not what AppArmor provides.  If I understand correctly, one
thing AppArmor does provide is a way to confine untrusted legacy
apps in a restricted jail.  That can be useful in some scenarios.
Consider, for instance, a web server where untrusted users can upload PHP
scripts, and you're concerned that those PHP scripts might be malicious.
Maybe you'd like to confine the PHP interpreter to limit what it can do.
That might be a good application for something like AppArmor.  You don't
need comprehensive information flow control for that kind of use, and
it would likely just get in the way.

Those who want a information flow control system, will probably use
SELinux or something like it.  Those who want what AppArmor has to offer,
might well use AppArmor.  They solve different problems and have different
tradeoffs.  There is room for more than one security tool in the world.

Re: AppArmor FAQ

[James Morris]

On Tue, 17 Apr 2007, David Wagner wrote:

> be more usable than SELinux.  Even if SELinux is more "complete"
> than AppArmor, I might still prefer ease of use over completeness
> and understandability.

I would challenge the claim that AppArmor offers any magic bullet for
ease of use.  There are plenty of examples of people disabling it because 
their apps stop working:

http://lists.opensuse.org/opensuse/2006-07/msg02440.html

  "Suddenly I have to disable AppArmor to start postfix."

Sound familiar ?

I'd also challenge the idea that the pathname policy scheme is easy enough 
for users to understand and meaningfully manage.  The chief architect of 
the project can't explain a simple policy he used to demonstrate its 
simplicity:

http://marc.info/?l=full-disclosure&m=114429157431167&w=2

"
  >  but as you posted an example profile with "capability setuid", I must
  > admit I am curious as to why an email client needs that.

  Well now that is a very good question, but it has nothing to do with
  AppArmor. The AppArmor learning mode just records the actions that the
  application performs. With or without AppArmor, the Thunderbird mail
  client is using cap_setuid. AppArmor gives you the opportunity to *deny*
  that capability, so you can try blocking it and find out. But for
  documentation on why Thunderbird needs it, you would have to look at
  mozilla.org not the AppArmor pages.

"

What this is demonstrates is that usability has nothing to do with 
pathnames or labels, and that the underlying complexity of the system 
dominates the issue.  In this case, the application needs a certain 
capability -- setuid, no less -- and the user doesn't understand why.  At 
this point, AppArmor loses its claimed transparency, and the user must 
ultimately understand what the system is doing and why.

SELinux, at the lowest level, simply exposes the complexity of the 
underlying security-relevant interactions of the system for the purposes 
of control.  Usability needs to be addressed at a higher level.

Something that is poorly understood is that SELinux policy was never 
intended to be developed by users.  It's like an assembly-language; it 
provides an extremely low-level mechanism for controlling all 
security-relevant accesses in the operating system.

The solution, as with programming languages (to continue the analogy), is 
to develop higher-level abstractions to hide the underlying complexity.  
Good progress has already been made in this area, and more is expected.

I certainly don't think the solution is to start out by ignoring the 
underlying complexity.



- James
-- 
James Morris
<jmorris@namei.org>

Re: AppArmor FAQ

[David Wagner]

James Morris  wrote:
>I would challenge the claim that AppArmor offers any magic bullet for
>ease of use.

There are, of course, no magic bullets for ease of use.
I would not make such a strong claim.  I simply stated that it
is plausible that AppArmor might have some advantages in some
deployment environments.

The purpose of LSM was to enable multiple different approaches to
security, so that we don't have to fight over the One True Way to
do it.  There might not be one best way for all situations.

These systems probably have different tradeoffs.  Consequently, it seems
to me that arguing over whether SELinux is superior to AppArmor makes
about as much sense as arguing over whether emacs is superior to vim,
or whether Python is superior to Perl.  The answer is likely to be
"it depends".

It's to be expected that SELinux developers prefer their own system
over AppArmor, or that AppArmor developers prefer AppArmor to SELinux.
(Have you ever seen any new parent who thinks their own baby is ugly?)
SELinux developers are likely to have built a system that addresses
the problems that seem important to them; other systems might set
priorities differently.

I think in this case the best remedy is to let many flowers bloom,
and let the users decide for themselves.

Re: AppArmor FAQ

[James Morris]

On Tue, 17 Apr 2007, David Wagner wrote:

> Maybe you'd like to confine the PHP interpreter to limit what it can do.
> That might be a good application for something like AppArmor.  You don't
> need comprehensive information flow control for that kind of use, and
> it would likely just get in the way.

SELinux can do this, it's policy-flexible.  You can even simulate a 
pathame-based policy language with a consequential loss of control:

http://seedit.sourceforge.net/

> might well use AppArmor.  They solve different problems and have different
> tradeoffs.  There is room for more than one security tool in the world.

That is not the point of this discussion, although we can at least be 
thankful that Linus didn't request that the networking layer be pluggable 
to the extent that the security layer is, otherwise we'd have a menagerie 
of "better" TCP stacks, TOE frameworks, STREAMS modules and whatever other 
fantastic ideas that people might be inclined to drag out of the kitchen 
sink.


- James
-- 
James Morris
<jmorris@namei.org>

Re: AppArmor FAQ

[David Wagner]

James Morris  wrote:
>On Tue, 17 Apr 2007, David Wagner wrote:
>> Maybe you'd like to confine the PHP interpreter to limit what it can do.
>> That might be a good application for something like AppArmor.  You don't
>> need comprehensive information flow control for that kind of use, and
>> it would likely just get in the way.
>
>SELinux can do this, it's policy-flexible.  You can even simulate a 
>pathame-based policy language with a consequential loss of control:

I have no doubt that SELinux can do that, but that has about as much
relevance to my point as the price of tea in China does.  I can use a
screwdriver to drive in a nail into my wall, too, if I really wanted to,
but that doesn't mean toolmakers should stop manufacturing hammers.

My point is that there are some tasks where it's plausible that AppArmor
might well be a better (easier-to-use) tool for the job.  I'm inclined
to suspect I might find it easier to use AppArmor for this kind of task
than SELinux, and I suspect I'm not the only one.  That doesn't mean
that AppArmor is somehow inherently superior to SELinux, or something
like that.

No one is claiming that AppArmor is "a better SELinux".  It solves
a somewhat different problem, and has a different set of tradeoffs.
It seems potentially useful.  That ought to be enough.  The world does
not revolve around SELinux.

Re: AppArmor FAQ

[James Morris]

On Wed, 18 Apr 2007, David Wagner wrote:

> These systems probably have different tradeoffs.  Consequently, it seems
> to me that arguing over whether SELinux is superior to AppArmor makes
> about as much sense as arguing over whether emacs is superior to vim,
> or whether Python is superior to Perl.  The answer is likely to be
> "it depends".

This is not what the discussion is about.  It's about addressing the many 
points in the FAQ posted here which are likely to cause misunderstandings, 
and then subsequent responses of a similar nature.



- James
-- 
James Morris
<jmorris@namei.org>

Re: AppArmor FAQ

[David Wagner]

James Morris  wrote:
>This is not what the discussion is about.  It's about addressing the many 
>points in the FAQ posted here which are likely to cause misunderstandings, 
>and then subsequent responses of a similar nature.

Thank you.  Then I misunderstood, and I owe you an apology.  Thank you
for your patience and for correcting my mistaken impression.

For what it's worth, I agreed with most or all of the comments you made
in your original response to the FAQ posted here.  I thought they were
constructive.  What got me to ranting was an email from Karl MacMillan
that seemed focused more on debating the merits of AppArmor rather than
on improving the FAQ.

Re: AppArmor FAQ

[David Lang]

remember that the windows NT permission model is theoreticly superior to the 
Unix permission model.

however there are far more insecure windows boxes out there then Unix boxes 
(even if taken as a percentage of the installed base)

I don't think that anyone is claiming that AA is superior to SELinux

what people are claiming is that the model AA is proposing can improve security 
in some cases.

to use the example from this thread /etc/resolv.conf

if you have a webserver that wants to do a name lookup you can do one of two 
things

1. in AA configure the webserver to have ro access to /etc/resolv.conf

2. in SELinux tag /etc/resolv.conf, figure out every program on the sytem that 
accesses it, and then tag those programs with the right permissions.

SELinux is designed to be able to make the box safe against root, AA is designed 
to let the admin harden exposed apps without having to think about the other 
things on the system.

allow people to use each tool for the appropriate task.

David Lang

On Wed, 18 Apr 2007, Rob Meijer wrote:

> Date: Wed, 18 Apr 2007 09:21:13 +0200 (CEST)
> From: Rob Meijer <capibara@xs4all.nl>
> To: Karl MacMillan <kmacmill@redhat.com>
> Cc: James Morris <jmorris@namei.org>, John Johansen <jjohansen@suse.de>,
>     linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org,
>     linux-fsdevel@vger.kernel.org
> Subject: Re: AppArmor FAQ
> 
> On Tue, April 17, 2007 23:55, Karl MacMillan wrote:
>> On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote:
>>> On Mon, 16 Apr 2007, John Johansen wrote:
>>>
>>>> Label-based security (exemplified by SELinux, and its predecessors in
>>>> MLS systems) attaches security policy to the data. As the data flows
>>>> through the system, the label sticks to the data, and so security
>>>> policy with respect to this data stays intact. This is a good approach
>>>> for ensuring secrecy, the kind of problem that intelligence agencies
>>> have.
>>>
>>> Labels are also a good approach for ensuring integrity, which is one of
>>> the most fundamental aspects of the security model implemented by
>>> SELinux.
>>>
>>> Some may infer otherwise from your document.
>>>
>>
>> Not only that, the implication that secrecy is only useful to
>> intelligence agencies is pretty funny. Personally, I think that
>> protecting the confidentiality of my data is important (and my bank and
>> health care providers protecting the data they have about me). Type
>> Enforcement was specifically designed to be able to address integrity
>> _and_ confidentiality in a way acceptable to commercial organizations.
>>
>> Karl
>
> Shouldn't that be _OR_, as I have always understood confidentialy
> models like BLP are by their very nature incompatible with integrity
> models like Biba. Given this incompatibity, I think the idea that
> BLP style use of lables (ss/* property and the likes) is only usefull
> to intelligence agencies may well be correct, while usage for integrity
> models like Biba and CW would be much broader than that.
>
> A path based 'least priviledge' (POLP) solution would I think on its own
> address neither integity nor confidentiality, and next to this would
> proof to be yet an other 'fat profile' administration hell.
>
> Having said that, I feel a path based solution could have great potential
> if it could be used in conjunction with the object capability model, that
> I would consider a simple and practical alternative integrity model that
> does not require lables in an MLS maner, and that extends on the POLP
> concept in a way that would be largely more practical.
> That is, using 'thin' path based profiles would become very practical if
> all further authority can be communicated using handles in the same way
> that an open file handle can be communicated.
>
> Rob
>
> -
> 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/
>

Re: AppArmor FAQ

[Rob Meijer]

On Tue, April 17, 2007 23:55, Karl MacMillan wrote:
> On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote:
>> On Mon, 16 Apr 2007, John Johansen wrote:
>>
>> > Label-based security (exemplified by SELinux, and its predecessors in
>> > MLS systems) attaches security policy to the data. As the data flows
>> > through the system, the label sticks to the data, and so security
>> > policy with respect to this data stays intact. This is a good approach
>> > for ensuring secrecy, the kind of problem that intelligence agencies
>> have.
>>
>> Labels are also a good approach for ensuring integrity, which is one of
>> the most fundamental aspects of the security model implemented by
>> SELinux.
>>
>> Some may infer otherwise from your document.
>>
>
> Not only that, the implication that secrecy is only useful to
> intelligence agencies is pretty funny. Personally, I think that
> protecting the confidentiality of my data is important (and my bank and
> health care providers protecting the data they have about me). Type
> Enforcement was specifically designed to be able to address integrity
> _and_ confidentiality in a way acceptable to commercial organizations.
>
> Karl

Shouldn't that be _OR_, as I have always understood confidentialy
models like BLP are by their very nature incompatible with integrity
models like Biba. Given this incompatibity, I think the idea that
BLP style use of lables (ss/* property and the likes) is only usefull
to intelligence agencies may well be correct, while usage for integrity
models like Biba and CW would be much broader than that.

A path based 'least priviledge' (POLP) solution would I think on its own
address neither integity nor confidentiality, and next to this would
proof to be yet an other 'fat profile' administration hell.

Having said that, I feel a path based solution could have great potential
if it could be used in conjunction with the object capability model, that
I would consider a simple and practical alternative integrity model that
does not require lables in an MLS maner, and that extends on the POLP
concept in a way that would be largely more practical.
That is, using 'thin' path based profiles would become very practical if
all further authority can be communicated using handles in the same way
that an open file handle can be communicated.

Rob

Re: AppArmor FAQ

[Joshua Brindle]

Rob Meijer wrote:
> On Tue, April 17, 2007 23:55, Karl MacMillan wrote:
>   
>> On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote:
>>     
>>> On Mon, 16 Apr 2007, John Johansen wrote:
>>>
>>>       
>>>> Label-based security (exemplified by SELinux, and its predecessors in
>>>> MLS systems) attaches security policy to the data. As the data flows
>>>> through the system, the label sticks to the data, and so security
>>>> policy with respect to this data stays intact. This is a good approach
>>>> for ensuring secrecy, the kind of problem that intelligence agencies
>>>>         
>>> have.
>>>
>>> Labels are also a good approach for ensuring integrity, which is one of
>>> the most fundamental aspects of the security model implemented by
>>> SELinux.
>>>
>>> Some may infer otherwise from your document.
>>>
>>>       
>> Not only that, the implication that secrecy is only useful to
>> intelligence agencies is pretty funny. Personally, I think that
>> protecting the confidentiality of my data is important (and my bank and
>> health care providers protecting the data they have about me). Type
>> Enforcement was specifically designed to be able to address integrity
>> _and_ confidentiality in a way acceptable to commercial organizations.
>>
>> Karl
>>     
>
> Shouldn't that be _OR_, as I have always understood confidentialy
> models like BLP are by their very nature incompatible with integrity
> models like Biba. Given this incompatibity, I think the idea that
> BLP style use of lables (ss/* property and the likes) is only usefull
> to intelligence agencies may well be correct, while usage for integrity
> models like Biba and CW would be much broader than that.
>   
Biba and BLP are only incompatible if they are using the same label, if 
each object has a confidentiality and integrity label they work fine 
together (as well as MLS systems work in general that is). Type 
enforcement, however, lets you accomplish both integrity and 
confidentiality (though not easily hierarchal confidentiality*). Take a 
mail client for example, I could argue that my mail is confidential so I 
label it my_mail_t and only give access to my mail client to read it and 
the MTA to write it. Further I limit access of my mail client to objects 
that can reduce its integrity such as untrusted files in /tmp, less 
trusted user home directories and so on. Despite AA advocate claims that 
info flow doesn't matter to integrity it does. I must be able to see 
what can write to objects that my mail client can read if I want to make 
any claims about its integrity.

* hierarchal confidentiality is obtained with an additional BLP label 
that is evaluated as set of constraints over the type enforcement 
permissions. SELinux is extensible in this way where AA is not.

> A path based 'least priviledge' (POLP) solution would I think on its own
> address neither integity nor confidentiality, and next to this would
> proof to be yet an other 'fat profile' administration hell.
>
> Having said that, I feel a path based solution could have great potential
> if it could be used in conjunction with the object capability model, that
> I would consider a simple and practical alternative integrity model that
> does not require lables in an MLS maner, and that extends on the POLP
> concept in a way that would be largely more practical.
>   
This would be combining two bad systems to get a worse one IMO. 
Capability systems are inherently discretionary since propagated 
capabilities must be removed at the discretion of the possessor of the 
capabilities.

The argument that labels are not practical has yet to be shown but is 
thrown around as if it is fact. Path based systems are inferior to label 
based systems based if for no other reason than path based systems can't 
control transient objects. With policy based type transition in SELinux 
when my ssh client writes my agent socket to /tmp/ssh-xxxxxxxxxx SELinux 
calculates a type transition based off my domain to label it 
sysadm_ssh_t (or whatever is appropriate) whereas path based systems 
can't possibly control access to these objects. The same goes for any 
files written to home directories by user apps.

> That is, using 'thin' path based profiles would become very practical if
> all further authority can be communicated using handles in the same way
> that an open file handle can be communicated.
>   

Once again, this creates a discretionary system that would not work 
without modifying every single application that uses such authority (and 
trusting the code is bug free so that it does the right thing) and gives 
you an inflexible, decentralized, unmaintainable, unanalyzable policy 
since it is distributed throughout code all over the system, you give 
users no way to change the security characteristics of the system.

Re: AppArmor FAQ

[Casey Schaufler]

--- Joshua Brindle <jbrindle@tresys.com> wrote:


> Biba and BLP are only incompatible if they are using the same label, if 
> each object has a confidentiality and integrity label they work fine 
> together

Joshua is correct here, although the original Biba observation was
that flipping BLP upside down results in an integrity model. Trusted
Irix uses (used?) both Biba and BLP.

> (as well as MLS systems work in general that is).

Doh! He had to get the dig in.



Casey Schaufler
casey@schaufler-ca.com

Re: AppArmor FAQ

[James Morris]

On Wed, 18 Apr 2007, David Lang wrote:

> SELinux is designed to be able to make the box safe against root, AA is
> designed to let the admin harden exposed apps without having to think about
> the other things on the system.

This is not correct.

SELinux was designed as an access control framework which allows various 
security models to be composed in a controlled and consistent manner, 
covering all security-relevant interactions in the system.

The type enforcement model included with it provides a means to address 
both integrity and confidentiality requirements.  It _can_ protect you 
against root, if that's what you want (in fact, the Russell Coker "play 
box" was online for many years with a published root password), but it 
does not have to.

Indeed, since Fedora Core 3, the default SELinux policy has been 
"targeted", which is aimed at confining exposed applications.



- James
-- 
James Morris
<jmorris@namei.org>

Re: AppArmor FAQ

[James Morris]

On Tue, 17 Apr 2007, Alan Cox wrote:

> I'm not sure if AppArmor can be made good security for the general case,
> but it is a model that works in the limited http environment
> (eg .htaccess) and is something people can play with and hack on and may
> be possible to configure to be very secure.

Perhaps -- until your httpd is compromised via a buffer overflow or 
simply misbehaves due to a software or configuration flaw, then the 
assumptions being made about its use of pathnames and their security 
properties are out the window.

Without security labeling of the objects being accessed, you can't protect 
against software flaws, which has been a pretty fundamental and widely 
understood requirement in general computing for at least a decade.


- James
-- 
James Morris
<jmorris@namei.org>

Re: AppArmor FAQ

[Rob Meijer]

On Wed, April 18, 2007 14:15, Joshua Brindle wrote:

>> Having said that, I feel a path based solution could have great
>> potential
>> if it could be used in conjunction with the object capability model,
>> that
>> I would consider a simple and practical alternative integrity model that
>> does not require lables in an MLS maner, and that extends on the POLP
>> concept in a way that would be largely more practical.
>>
> This would be combining two bad systems to get a worse one IMO.
> Capability systems are inherently discretionary since propagated
> capabilities must be removed at the discretion of the possessor of the
> capabilities.

That is assuming there is no caretaker or membrane implementation in the
delegation chain, but I don't think we need to get into such details of
object capabilities here. Point is there are ways to delegate revocable
capabilities when using the OC model when required.

> The argument that labels are not practical has yet to be shown but is
> thrown around as if it is fact. Path based systems are inferior to label
> based systems based if for no other reason than path based systems can't
> control transient objects. With policy based type transition in SELinux
> when my ssh client writes my agent socket to /tmp/ssh-xxxxxxxxxx SELinux
> calculates a type transition based off my domain to label it
> sysadm_ssh_t (or whatever is appropriate) whereas path based systems
> can't possibly control access to these objects. The same goes for any
> files written to home directories by user apps.

I fully agree that path based security is inferior 'when used on its own'.

>> That is, using 'thin' path based profiles would become very practical if
>> all further authority can be communicated using handles in the same way
>> that an open file handle can be communicated.
>>
>
> Once again, this creates a discretionary system that would not work
> without modifying every single application that uses such authority

It creates a discretionary enviroment that makes it much more natural
for developers to create cooperating subsystems that are designed
from an least authority perspective. And it creates the means to
configure the system for such programs with a minimum amounth of
profile information.

Next to this, but a bit more complicated, path based security could in
theory be used to make required authority explicitly designated. That is
calling :

  cp ~/foo.txt ~/bar_directory/

could ultimately explicitly transfer the user his authorities to both
~/foo.txt and ~/bar_directory/ to this instance of 'cp', but without
transfering any other ambient authority. This example may be a bit
out of the current range for AppArmor, but I feel it demonstrates that
path based security may have potential added value in a least authority
context.

That is if Allice has authority to ~/, and ~/ contains ~/important.doc
and allice has rw access to ~/important.doc, than ultimately invoking 'cp
~/foo.txt ~/bar_directory/' should not give the 'cp' instance the
authority to read/write ~/important.doc, but invoking 'cp ~/foo.doc
~/important.doc'
should. That is, if we want cp to work unmodified.

> (and
> trusting the code is bug free so that it does the right thing)

I think the abouve shows that it actualy requeres 'less' trust in
code if implemented right.

> and gives
> you an inflexible, decentralized, unmaintainable, unanalyzable policy
> since it is distributed throughout code all over the system, you give
> users no way to change the security characteristics of the system.

I agree with the decentralized part, but in my view accomodating and
allowing free and optionaly revocable delegation (you can always proxy
anyway, so we know blocking it is misguided) makes for a much more
flexible and esspecialy usable form of security.
Systems designed according to POLA are definetely the most easy to
do formal analysis of security properties on.

I am not saying that path-based + OC would be 'better' than label based,
I feel both would have their own level of granularity where they are
usefull, and in some cases they could be complementary.

I feel path based would be useless when possitioned purely as MAC, but
when possitioned more as least authority bootstrap and designation
mechanism complementary to least authority design ant usage of the OC model,
I think path based may have some concrete use.

sidenote: it is amusing to see that many OC advocates use many of your
arguments (inflexible, unmaintainable, hard to analyze) to dismiss many
label based MLS models as viable security models;-)

Rob

Re: AppArmor FAQ

[Shaya Potter]

James Morris wrote:
> On Tue, 17 Apr 2007, Alan Cox wrote:
> 
>> I'm not sure if AppArmor can be made good security for the general case,
>> but it is a model that works in the limited http environment
>> (eg .htaccess) and is something people can play with and hack on and may
>> be possible to configure to be very secure.
> 
> Perhaps -- until your httpd is compromised via a buffer overflow or 
> simply misbehaves due to a software or configuration flaw, then the 
> assumptions being made about its use of pathnames and their security 
> properties are out the window.
> 
> Without security labeling of the objects being accessed, you can't protect 
> against software flaws, which has been a pretty fundamental and widely 
> understood requirement in general computing for at least a decade.

And that's why apparmor should be implemented as a stackable file system 
with a container mechanism, and I implemented such a thing back in 2003, 
albiet mostly just proof of concept and a horribly written paper (it was 
my first), so never got published beyond a tech report.

http://www.ncl.cs.columbia.edu/publications/cucs-005-04.pdf

Basically, on disk labeling is not necessarily an easy mechanism for app 
armor type things as it's not easy to use and different applications 
have different requirements so end up w/ multiple labels attached that 
are difficult to understand.  That's why app armor's path based rules 
are nice, each app has its own set of rules, and one can easily eyeball 
what rules apply to each app, as well as easily change it.  However, 
since apparmor has no conception of the actual file system, so it's 
broken by design.

If on the other hand it was implemented as a stackable file system, each 
fs object would be labeled.  The same underlying FS could be used by 
multiple distinct applications w/ distinct security issues, and one 
could even combine it with something like unionfs to give each domain a 
separate writable area, avoiding the "output file issue", where output 
filess could be used to attack the system.

Re: AppArmor FAQ

[Crispin Cowan]

James Morris wrote:
> On Tue, 17 Apr 2007, Alan Cox wrote:
>   
>> I'm not sure if AppArmor can be made good security for the general case,
>> but it is a model that works in the limited http environment
>> (eg .htaccess) and is something people can play with and hack on and may
>> be possible to configure to be very secure.
>>     
> Perhaps -- until your httpd is compromised via a buffer overflow or 
> simply misbehaves due to a software or configuration flaw, then the 
> assumptions being made about its use of pathnames and their security 
> properties are out the window.
>   
How is it that you think a buffer overflow in httpd could allow an
attacker to break out of an AppArmor profile? This is exactly what
AppArmor was designed to do, and without specifics, this is just FUD.

> Without security labeling of the objects being accessed, you can't protect 
> against software flaws, which has been a pretty fundamental and widely 
> understood requirement in general computing for at least a decade.
>   
Please explain why labels are necessary for effective confinement. Many
systems besides AppArmor have used non-label schemes for effective
confinement: TRON, Janus, LIDS, Systrace, BSD Jail, EROS, PSOS, KeyOS,
AS400, to name just a few. This claim seems bogus. Labels may be your
method of choice for confinement, but they are far from the only way.

Crispin

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

Re: AppArmor FAQ

[Shaya Potter]

On Wed, 18 Apr 2007, Crispin Cowan wrote:

> Please explain why labels are necessary for effective confinement. Many
> systems besides AppArmor have used non-label schemes for effective
> confinement: TRON, Janus, LIDS, Systrace, BSD Jail, EROS, PSOS, KeyOS,
> AS400, to name just a few. This claim seems bogus. Labels may be your
> method of choice for confinement, but they are far from the only way.

One problem with AppArmor and Janus and Systrace and everything else that 
relies on pathname resolution is the point where they do the pathname 
resolution.

If you read the janus, systrace, subdomain (apparmor's predecssor?) 
papers, you'll see how they have to jump through hoops to handle things 
like symlinks, when there's no fundamental reason why they have to.

If one simply worked at the FS level, all one cares about is lookup() and 
permission.  You have a set of rules that lookup() is able to use to 
dynamically tag dentries and permission() then checks that tag.  One 
doesn't jump through hoops anymore.

So, while I sound like a broken record, something like a stackable file 
system works wonders here (I know, I implemented one).  Now, stackable 
file systems aren't perfect here (mount point crossing, additional mounted 
file systems on top of the stackable file system) can cause problems, 
overall it seems like a cleaner solution.

Another option would be if the LSM could be extended to allow a simple 
method of storing "private" data along with every dentry/inode (the main 
reason one needs a stackable file system).  In this way, if the lookup() 
oepration was extended to be able to take a function that filled in that 
data and permission() was able to be extended to take a function that 
could use that data, one wouldn't even need a stackable file system, but 
one would still be operating at the simplest layer (which is the file 
system).

Re: AppArmor FAQ

[David Lang]

On Wed, 18 Apr 2007, James Morris wrote:

> On Tue, 17 Apr 2007, Alan Cox wrote:
>
>> I'm not sure if AppArmor can be made good security for the general case,
>> but it is a model that works in the limited http environment
>> (eg .htaccess) and is something people can play with and hack on and may
>> be possible to configure to be very secure.
>
> Perhaps -- until your httpd is compromised via a buffer overflow or
> simply misbehaves due to a software or configuration flaw, then the
> assumptions being made about its use of pathnames and their security
> properties are out the window.

since AA defines a whitelist of files that httpd is allowed to access, a 
comprimised one may be able to mess up it's files, but it's still not going to 
be able to touch other files on the system.

> Without security labeling of the objects being accessed, you can't protect
> against software flaws, which has been a pretty fundamental and widely
> understood requirement in general computing for at least a decade.

this is not true. you don't need to label all object and chunks of memory, you 
just need to have a way to list (and enforce) the objects and memory that the 
program is allowed to use. labeling them is one way of doing this, but not the 
only way.

David Lang

Re: AppArmor FAQ

[James Morris]

On Wed, 18 Apr 2007, Crispin Cowan wrote:

> James Morris wrote:
> > On Tue, 17 Apr 2007, Alan Cox wrote:
> >   
> >> I'm not sure if AppArmor can be made good security for the general case,
> >> but it is a model that works in the limited http environment
> >> (eg .htaccess) and is something people can play with and hack on and may
> >> be possible to configure to be very secure.
> >>     
> > Perhaps -- until your httpd is compromised via a buffer overflow or 
> > simply misbehaves due to a software or configuration flaw, then the 
> > assumptions being made about its use of pathnames and their security 
> > properties are out the window.
> >   
> How is it that you think a buffer overflow in httpd could allow an
> attacker to break out of an AppArmor profile?

Because you can change the behavior of the application and then bypass 
policy entirely by utilizing any mechanism other than direct filesystem 
access: IPC, shared memory, Unix domain sockets, local IP networking, 
remote networking etc.

This not even considering object aliasing (which would allow you to 
inappropriately access objects with full blessing of policy), as I'm 
assuming that the limited environment Alan is referring to entirely 
prevents them.

Also worth noting here is that you have to consider any limited 
environment as enforcing security policy, and thus its configuration 
becomes an additional component of security policy.

So, your real security policy is actually more complicated than it appears 
to be, is not represented completely in the policy configuration file, and 
must be managed disparately.  And it's still only capable of controlling 
access to filesystem objects.



- James
-- 
James Morris
<jmorris@namei.org>

Re: AppArmor FAQ

[David Wagner]

James Morris  wrote:
>On Wed, 18 Apr 2007, Crispin Cowan wrote:
>> How is it that you think a buffer overflow in httpd could allow an
>> attacker to break out of an AppArmor profile?
>
>Because you can change the behavior of the application and then bypass 
>policy entirely by utilizing any mechanism other than direct filesystem 
>access: IPC, shared memory, Unix domain sockets, local IP networking, 
>remote networking etc.

Any halfway decent jail will let you control access to all of those
things, thereby preventing an 0wned httpd from breaking out of the jail.
(For instance, Janus did.  So does Systrace.)

Are you saying AppArmor does not allow that kind of control?  Specifics
would be useful.

>Also worth noting here is that you have to consider any limited 
>environment as enforcing security policy, and thus its configuration 
>becomes an additional component of security policy.

I don't understand what you are saying.  Yes, the AppArmor policy
file is part of policy.  Is that what you mean?

Re: AppArmor FAQ

[Stephen Smalley]

On Wed, 2007-04-18 at 12:41 -0700, Crispin Cowan wrote:
> James Morris wrote:
> > On Tue, 17 Apr 2007, Alan Cox wrote:
> >   
> >> I'm not sure if AppArmor can be made good security for the general case,
> >> but it is a model that works in the limited http environment
> >> (eg .htaccess) and is something people can play with and hack on and may
> >> be possible to configure to be very secure.
> >>     
> > Perhaps -- until your httpd is compromised via a buffer overflow or 
> > simply misbehaves due to a software or configuration flaw, then the 
> > assumptions being made about its use of pathnames and their security 
> > properties are out the window.
> >   
> How is it that you think a buffer overflow in httpd could allow an
> attacker to break out of an AppArmor profile? This is exactly what
> AppArmor was designed to do, and without specifics, this is just FUD.
> 
> > Without security labeling of the objects being accessed, you can't protect 
> > against software flaws, which has been a pretty fundamental and widely 
> > understood requirement in general computing for at least a decade.
> >   
> Please explain why labels are necessary for effective confinement. Many
> systems besides AppArmor have used non-label schemes for effective
> confinement: TRON, Janus, LIDS, Systrace, BSD Jail, EROS, PSOS, KeyOS,
> AS400, to name just a few. This claim seems bogus. Labels may be your
> method of choice for confinement, but they are far from the only way.

Confinement in its traditional sense (e.g. the 1973 Lampson paper, ACM
Vol 16 No 10) means information flow control, which you have agreed
AppArmor does not and cannot provide.  Yes?  As to the (genuine)
capability-based systems, have a look at the DTOS General System
Security and Assurability Assessment Report for why we have concerns
with their approach.  But that has nothing to do with AppArmor.

Look, if you would just refrain from making misleading statements about
SELinux (not only in this FAQ but throughout your documents and talks),
especially when we've previously refuted those same statements (as in
the first AppArmor submission and its discussion), and honestly
acknowledged the limitations of your approach without trying to spin
them as strengths, I think that there would be nothing to discuss here.
We could just agree to disagree, and you could just focus on addressing
the issues raised by the vfs folks about how to get your changes into an
acceptable form.

-- 
Stephen Smalley
National Security Agency

Re: AppArmor FAQ

[Stephen Smalley]

On Wed, 2007-04-18 at 13:15 -0700, David Lang wrote:
> On Wed, 18 Apr 2007, James Morris wrote:
> 
> > On Tue, 17 Apr 2007, Alan Cox wrote:
> >
> >> I'm not sure if AppArmor can be made good security for the general case,
> >> but it is a model that works in the limited http environment
> >> (eg .htaccess) and is something people can play with and hack on and may
> >> be possible to configure to be very secure.
> >
> > Perhaps -- until your httpd is compromised via a buffer overflow or
> > simply misbehaves due to a software or configuration flaw, then the
> > assumptions being made about its use of pathnames and their security
> > properties are out the window.
> 
> since AA defines a whitelist of files that httpd is allowed to access, a 
> comprimised one may be able to mess up it's files, but it's still not going to 
> be able to touch other files on the system.
> 
> > Without security labeling of the objects being accessed, you can't protect
> > against software flaws, which has been a pretty fundamental and widely
> > understood requirement in general computing for at least a decade.
> 
> this is not true. you don't need to label all object and chunks of memory, you 
> just need to have a way to list (and enforce) the objects and memory that the 
> program is allowed to use. labeling them is one way of doing this, but not the 
> only way.

You need a way of providing global and persistent security guarantees
for the data, and per-program profiles based on pathname don't get you
there.  There is no system view in AA, just a bunch of disconnected
profiles.

-- 
Stephen Smalley
National Security Agency

Re: AppArmor FAQ

[Stephen Smalley]

On Thu, 2007-04-19 at 16:35 +0000, David Wagner wrote:
> James Morris  wrote:
> >On Wed, 18 Apr 2007, Crispin Cowan wrote:
> >> How is it that you think a buffer overflow in httpd could allow an
> >> attacker to break out of an AppArmor profile?
> >
> >Because you can change the behavior of the application and then bypass 
> >policy entirely by utilizing any mechanism other than direct filesystem 
> >access: IPC, shared memory, Unix domain sockets, local IP networking, 
> >remote networking etc.
> 
> Any halfway decent jail will let you control access to all of those
> things, thereby preventing an 0wned httpd from breaking out of the jail.
> (For instance, Janus did.  So does Systrace.)
> 
> Are you saying AppArmor does not allow that kind of control?  Specifics
> would be useful.

Just look at their code and their own description of AppArmor.  It does
not provide that level of control, and by your own metric, it is thus
not a halfway decent jail.  Which begs the question - if that is the
kind of approach you want, why not use a real jail/containers mechanism
for it?

> >Also worth noting here is that you have to consider any limited 
> >environment as enforcing security policy, and thus its configuration 
> >becomes an additional component of security policy.
> 
> I don't understand what you are saying.  Yes, the AppArmor policy
> file is part of policy.  Is that what you mean?

I think he means the dependencies on which AppArmor relies, not just its
policy, e.g. since it is name-based, it presumes the filesystem
namespace has been set up by a trusted agent and is correct. 

-- 
Stephen Smalley
National Security Agency

Re: AppArmor FAQ

[Stephen Smalley]

On Tue, 2007-04-17 at 20:05 +0200, Andi Kleen wrote:
> Karl MacMillan <kmacmill@redhat.com> writes:
>  
> > No - the real fix is to change the applications or to run under a policy
> > that confines all applications. Most of the problems with resolv.conf,
> > mtab, etc. stem from admin processes (e.g., editors or shell scripts)
> > all running under the same unconfined domain.
> > 
> > In some cases applications need modification as only the application has
> > enough information to determine the correct label. Usually this means
> > preserving labels from input files or separating the output into
> > distinct directories so type transitions or label inheritance will work.
> > 
> > restorecond is just a hack not a requirement or a sign that something is
> > wrong with the model. That is why it is a userspace application and not
> > integrated into the kernel mechanism.
> 
> You nicely show one of the major disadvantages of the label model vs the path 
> model here: it requires modification of a lot of applications. 

It is true that many applications that already deal with mode bits need
to become aware of labels, just as with ACLs, and that this makes it a
bit harder and slower to roll out something that is label-based.  But
the right solution is rarely quick and easy, and a lot of work has
already happened to integrate such support into userland.

To look at it in a slightly different way, the AA emphasis on not
modifying applications could be viewed as a limitation.  Ultimately,
users have security goals that go beyond just what the OS can directly
enforce and at least some applications (notably things like X, D-BUS,
PostgreSQL, etc) need to likewise support strong domain separation and
controlled information flow through their own internal objects and
operations.  SELinux provides APIs and infrastructure for such
applications, and has already done quite a bit of work in that space
(D-BUS support, XACE/XSELinux, SE-PostgreSQL), whereas AA seems to have
no interest in going there (and would have to recant its emphasis on no
application mods to do so).  If you actually want to truly confine a
desktop application, you can't limit yourself to the kernel.  And the
label model provides a unifying abstraction for dealing with all of
these various objects, whereas the path/"natural abstraction" model has
no unifying abstraction at all.

-- 
Stephen Smalley
National Security Agency

Re: AppArmor FAQ

[Stephen Smalley]

On Tue, 2007-04-17 at 16:09 -0700, Crispin Cowan wrote:
> David Safford wrote:
> > On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote:
> >   
> >> On Mon, 16 Apr 2007, John Johansen wrote:
> >>     
> >>> Label-based security (exemplified by SELinux, and its predecessors in
> >>> MLS systems) attaches security policy to the data. As the data flows
> >>> through the system, the label sticks to the data, and so security
> >>> policy with respect to this data stays intact. This is a good approach
> >>> for ensuring secrecy, the kind of problem that intelligence agencies have.
> >>>       
> >> Labels are also a good approach for ensuring integrity, which is one of 
> >> the most fundamental aspects of the security model implemented by SELinux.  
> >>
> >> Some may infer otherwise from your document.
> >>     
> > In fact, I am not sure how you can provide integrity support without
> > labels. AppArmor confines a process, but does not effectively confine 
> > its output files, precisely because the output files are not labeled. 
> > Other processes are free to access the unlabeled, potentially malicious 
> > output files without restriction. 
> >   
> That depends on what you mean by "integrity." It is true that AppArmor
> does not directly manage information flow. AppArmor assumes that if you
> granted write permission to /etc/resolv.conf, that you meant to do that.
> Whether any other process is permitted to access /etc/resolv.conf is
> determined by those other process's respective profiles.

Integrity protection requires information flow control; you can't
protect a high integrity process from being corrupted by a low integrity
process if you don't control the flow of information.  Plenty of attacks
take the form of a untrusted process injecting data that will ultimately
be used by a more trusted process with a surprising side effect.

And you can't do information flow control if you can't provide global
and persistent protection of the data, which requires labeling it and
preserving that label for its lifetime.

> What AppArmor provides is a way for administrators to confine software
> that they have to run but do not trust. The use of pathnames means that
> the administrator can understand the exact meaning of the security
> policy, without having to do a complete labeling of the file system. The
> flip side of not managing information flow is that each profile is
> independent of every other profile.

They aren't truly independent; the composition may lead to surprising
results where each individual program is "confined" exactly as you
specified, but in combination, one is able to corrupt the higher
integrity subject by actions taken by the lower integrity subject.
Particularly in the fun area of publically writable directories, where
pathnames are largely useless as an indicator.

-- 
Stephen Smalley
National Security Agency

Re: AppArmor FAQ

[Bernd Eckenfels]

In article <Line.LNX.4.64.0704180935100.25495@d.namei> you wrote:
> Perhaps -- until your httpd is compromised via a buffer overflow or 
> simply misbehaves due to a software or configuration flaw, then the 
> assumptions being made about its use of pathnames and their security 
> properties are out the window.

Hu? Even a compromised httpd (especially a compromised httpd) is bound to
the app armor policies. This means it cannot (for example) write to
/var/www/* - if it never needed to at normal/profiling time.

Gruss
Bernd

Re: AppArmor FAQ

[David Wagner]

Stephen Smalley  wrote:
>Confinement in its traditional sense (e.g. the 1973 Lampson paper, ACM
>Vol 16 No 10) means information flow control, which you have agreed
>AppArmor does not and cannot provide.

Right, that's how I understand it, too.

However, I think some more caveats are in order.  In all honesty,
I don't think SELinux solves Lampson's problem, either.

It is useful to distinguish between "bit-confinement" (confining the
flow of information, a la Lampson) vs "authority-confinement" (confining
the flow of privileges and the ability of the untrusted app to cause
side effects on the rest of the system).

No Linux system provides bit-confinement, if the confined app is
malicious.  AppArmor does not provide bit-confinement.  Neither does
SELinux.  SELinux can stop some kinds of accidental leakage of secrets,
but it cannot prevent deliberate attempts to leak the secrets that are
known to malicious apps.  The reason is that, in every system under
consideration, it is easy for a malicious app to leak any secrets it might
have to the outside world by using covert channels (e.g., wall-banging).
In practical terms, Lampson's bit-confinement problem is just not
solvable.  Oh well, so it goes.

A good jail needs to provide authority-confinement, but thankfully,
it doesn't need to provide bit-confinement.  I don't know enough about
AppArmor to know whether it is able to do a good job of providing
authority-confinement.  If it cannot, then it deserves criticism on
those grounds.

Often the pragmatic solution to the covert channel problem is to ensure
that untrusted apps are never given access to critical secrets in the
first place.  They can't leak something they don't know.  This solves the
confidentiality problem by avoiding any attempt to tackle the unsolvable
bit-confinement problem.

Note that the problem of building a good jail is a little different from
the information flow control problem.

Re: AppArmor FAQ

[James Morris]

On Thu, 19 Apr 2007, Bernd Eckenfels wrote:

> In article <Line.LNX.4.64.0704180935100.25495@d.namei> you wrote:
> > Perhaps -- until your httpd is compromised via a buffer overflow or 
> > simply misbehaves due to a software or configuration flaw, then the 
> > assumptions being made about its use of pathnames and their security 
> > properties are out the window.
> 
> Hu? Even a compromised httpd (especially a compromised httpd) is bound to
> the app armor policies. This means it cannot (for example) write to
> /var/www/* - if it never needed to at normal/profiling time.

This has been addressed several times already, please read the full 
thread.



- James
-- 
James Morris
<jmorris@namei.org>

Re: AppArmor FAQ

[David Wagner]

Crispin Cowan wrote:
> How is it that you think a buffer overflow in httpd could allow an
> attacker to break out of an AppArmor profile?

James Morris  wrote:
> [...] you can change the behavior of the application and then bypass 
> policy entirely by utilizing any mechanism other than direct filesystem 
> access: IPC, shared memory, Unix domain sockets, local IP networking, 
> remote networking etc.
[...]
> Just look at their code and their own description of AppArmor.

My gosh, you're right.  What the heck?  With all due respect to the
developers of AppArmor, I can't help thinking that that's pretty lame.
I think this raises substantial questions about the value of AppArmor.
What is the point of having a jail if it leaves gaping holes that
malicious code could use to escape?

And why isn't this documented clearly, with the implications fully
explained?

I would like to hear the AppArmor developers defend this design decision.
When we developed Janus, over 10 years ago, we defended against these
attack avenues and protected everything -- not just the filesystem.
Systrace does the same, as does Plash.  So does Consh, and MapBox, and
Ostia, to name a few other examples from the research world.  This is
standard stuff that is well-documented in the literature, and it seems to
me it is necessary before you can claim to have a useful jail.  What am
I missing?


P.S. I think the criticisms that "AppArmor is pathname-based" or
"AppArmor doesn't do everything SELinux does" or "AppArmor doesn't do
information flow control" are weak.  But the criticism that "AppArmor
leaves security holes that can be used to escape the jail" seems like
a serious criticism to me.  Perhaps a change of focus is in order.

Re: AppArmor FAQ

[David Wagner]

Stephen Smalley  wrote:
>Integrity protection requires information flow control; you can't
>protect a high integrity process from being corrupted by a low integrity
>process if you don't control the flow of information.  Plenty of attacks
>take the form of a untrusted process injecting data that will ultimately
>be used by a more trusted process with a surprising side effect.

I don't agree with this blanket statement.  In a number of cases
of practical interest, useful integrity protection can be achieved
without full information flow control.  Suppose you have a malicious
("low integrity") process A, and a target ("high integrity") process B.
We want to prevent A from attacking B.  One way to do that is to ensure
that A has no overt channel it can use to attack process B, by severely
restricting A's ability to cause side effects on the rest of the world.
This is often sufficient to contain the damage that A can do.

Of course, if the intended functionality of the system requires A to
communicate data to B, and if you don't trust B's ability to handle
that data carefully enough, and if A is malicious, then you've got a
serious problem.

But in a number of cases (enough cases to be useful), you can provide
a useful level of security without needing information flow control and
without needing global, persistent labels.

Re: AppArmor FAQ

[Stephen Smalley]

On Thu, 2007-04-19 at 20:08 +0000, David Wagner wrote:
> Stephen Smalley  wrote:
> >Confinement in its traditional sense (e.g. the 1973 Lampson paper, ACM
> >Vol 16 No 10) means information flow control, which you have agreed
> >AppArmor does not and cannot provide.
> 
> Right, that's how I understand it, too.
> 
> However, I think some more caveats are in order.  In all honesty,
> I don't think SELinux solves Lampson's problem, either.
> 
> It is useful to distinguish between "bit-confinement" (confining the
> flow of information, a la Lampson) vs "authority-confinement" (confining
> the flow of privileges and the ability of the untrusted app to cause
> side effects on the rest of the system).
> 
> No Linux system provides bit-confinement, if the confined app is
> malicious.  AppArmor does not provide bit-confinement.  Neither does
> SELinux.  SELinux can stop some kinds of accidental leakage of secrets,
> but it cannot prevent deliberate attempts to leak the secrets that are
> known to malicious apps.  The reason is that, in every system under
> consideration, it is easy for a malicious app to leak any secrets it might
> have to the outside world by using covert channels (e.g., wall-banging).
> In practical terms, Lampson's bit-confinement problem is just not
> solvable.  Oh well, so it goes.
> 
> A good jail needs to provide authority-confinement, but thankfully,
> it doesn't need to provide bit-confinement.  I don't know enough about
> AppArmor to know whether it is able to do a good job of providing
> authority-confinement.  If it cannot, then it deserves criticism on
> those grounds.
> 
> Often the pragmatic solution to the covert channel problem is to ensure
> that untrusted apps are never given access to critical secrets in the
> first place.  They can't leak something they don't know.  This solves the
> confidentiality problem by avoiding any attempt to tackle the unsolvable
> bit-confinement problem.
> 
> Note that the problem of building a good jail is a little different from
> the information flow control problem.

First, I think there is practical value in providing confidentiality
control on the overt channels, even if covert channels remain.  We have
to start somewhere.

Second, information flow is not just a confidentiality issue - see my
other email.  It is quite important as well for integrity, and integrity
corruption in order to assume control over a privileged subject or trick
it into abusing its power can be done solely via a data channel - it
doesn't require explicit flow of authority.

Lastly, if you want to judge AA as a jail mechanism, I think you'll find
it fails there too.  So where does that leave it?  An easy-to-use yet
inadequate solution for MAC or jail.

-- 
Stephen Smalley
National Security Agency

Re: AppArmor FAQ

[James Morris]

On Thu, 19 Apr 2007, Stephen Smalley wrote:

> Lastly, if you want to judge AA as a jail mechanism, I think you'll find
> it fails there too.  So where does that leave it?  An easy-to-use yet
> inadequate solution for MAC or jail.

It's not easy to use.


-- 
James Morris
<jmorris@namei.org>

Re: AppArmor FAQ

[Stephen Smalley]

On Thu, 2007-04-19 at 20:54 +0000, David Wagner wrote:
> Stephen Smalley  wrote:
> >Integrity protection requires information flow control; you can't
> >protect a high integrity process from being corrupted by a low integrity
> >process if you don't control the flow of information.  Plenty of attacks
> >take the form of a untrusted process injecting data that will ultimately
> >be used by a more trusted process with a surprising side effect.
> 
> I don't agree with this blanket statement.  In a number of cases
> of practical interest, useful integrity protection can be achieved
> without full information flow control.  Suppose you have a malicious
> ("low integrity") process A, and a target ("high integrity") process B.
> We want to prevent A from attacking B.  One way to do that is to ensure
> that A has no overt channel it can use to attack process B, by severely
> restricting A's ability to cause side effects on the rest of the world.
> This is often sufficient to contain the damage that A can do.

If you could do that, I'd call that information flow control - I wasn't
saying you had to eliminate covert channels.  As you said, we don't deal
with those even in SELinux.  The point is that AA can't even do that,
not only because it has incomplete controls but because it bases its
decisions on unreliable identifiers (paths) that doesn't let it provide
global and persistent protection of the data.

> Of course, if the intended functionality of the system requires A to
> communicate data to B, and if you don't trust B's ability to handle
> that data carefully enough, and if A is malicious, then you've got a
> serious problem.
> 
> But in a number of cases (enough cases to be useful), you can provide
> a useful level of security without needing information flow control and
> without needing global, persistent labels.

Without a reliable way of identifying the data in a system view, you
can't say anything at all about the data flows.  The labels provide you
with a way of doing that.  The paths are ambiguous, highly mutable, and
often meaningless (particularly for runtime files, temporary files, etc)
from a security pov.

Simple example:  malicious symlink attacks.

-- 
Stephen Smalley
National Security Agency

Re: AppArmor FAQ

[David Lang]

On Thu, 19 Apr 2007, Stephen Smalley wrote:

> already happened to integrate such support into userland.
>
> To look at it in a slightly different way, the AA emphasis on not
> modifying applications could be viewed as a limitation.  Ultimately,
> users have security goals that go beyond just what the OS can directly
> enforce and at least some applications (notably things like X, D-BUS,
> PostgreSQL, etc) need to likewise support strong domain separation and
> controlled information flow through their own internal objects and
> operations.  SELinux provides APIs and infrastructure for such
> applications, and has already done quite a bit of work in that space
> (D-BUS support, XACE/XSELinux, SE-PostgreSQL), whereas AA seems to have
> no interest in going there (and would have to recant its emphasis on no
> application mods to do so).  If you actually want to truly confine a
> desktop application, you can't limit yourself to the kernel.  And the
   ^^^^^^^^^^^^^^^^^^^

> label model provides a unifying abstraction for dealing with all of
> these various objects, whereas the path/"natural abstraction" model has
> no unifying abstraction at all.


AA isn't aimed at confineing desktop applications. it's aimed at confining 
server applications. this really is a easier task (if it happens to be useful 
for some desktop apps as well, so much the better)

David Lang

Re: AppArmor FAQ

[Karl MacMillan]

On Fri, 2007-04-20 at 11:45 -0700, David Lang wrote:
> On Thu, 19 Apr 2007, Stephen Smalley wrote:
> 
> > already happened to integrate such support into userland.
> >
> > To look at it in a slightly different way, the AA emphasis on not
> > modifying applications could be viewed as a limitation.  Ultimately,
> > users have security goals that go beyond just what the OS can directly
> > enforce and at least some applications (notably things like X, D-BUS,
> > PostgreSQL, etc) need to likewise support strong domain separation and
> > controlled information flow through their own internal objects and
> > operations.  SELinux provides APIs and infrastructure for such
> > applications, and has already done quite a bit of work in that space
> > (D-BUS support, XACE/XSELinux, SE-PostgreSQL), whereas AA seems to have
> > no interest in going there (and would have to recant its emphasis on no
> > application mods to do so).  If you actually want to truly confine a
> > desktop application, you can't limit yourself to the kernel.  And the
>    ^^^^^^^^^^^^^^^^^^^
> 
> > label model provides a unifying abstraction for dealing with all of
> > these various objects, whereas the path/"natural abstraction" model has
> > no unifying abstraction at all.
> 
> 
> AA isn't aimed at confineing desktop applications. it's aimed at confining 
> server applications. this really is a easier task (if it happens to be useful 
> for some desktop apps as well, so much the better)
> 

Steve's point holds equally well for server applications - SE-PostgreSQl
is a good example.

Karl

Re: AppArmor FAQ

[Crispin Cowan]

David Wagner wrote:
> James Morris  wrote:
>   
>> [...] you can change the behavior of the application and then bypass 
>> policy entirely by utilizing any mechanism other than direct filesystem 
>> access: IPC, shared memory, Unix domain sockets, local IP networking, 
>> remote networking etc.
>>     
> [...]
>   
>> Just look at their code and their own description of AppArmor.
>>     
> My gosh, you're right.  What the heck?  With all due respect to the
> developers of AppArmor, I can't help thinking that that's pretty lame.
> I think this raises substantial questions about the value of AppArmor.
> What is the point of having a jail if it leaves gaping holes that
> malicious code could use to escape?
>
> And why isn't this documented clearly, with the implications fully
> explained?
>
> I would like to hear the AppArmor developers defend this design decision.
>   
It was a simplicity trade off at the time, when AppArmor was mostly
aimed at servers, and there was no HAL or DBUS. Now it is definitely a
limitation that we are addressing. We are working on a mediation system
for what kind of IPC a confined process can do
http://forge.novell.com/pipermail/apparmor-dev/2007-April/000503.html

When our IPC mediation system is code instead of vapor, it will also
appear here for review. Meanwhile, AppArmor does not make IPC security
any worse, confined processes are still subject to the usual Linux IPC
restrictions. AppArmor actually makes the IPC situation somewhat more
secure than stock Linux, e.g. normal DBUS deployment can be controlled
through file access permissions. But we are not claiming AppArmor to be
an IPC security enhancement, yet.

The proposed set of patches is a self-contained access control system
for file system access, and we would like it reviewed as such. Current
AppArmor docs are quite explicit that AppArmor only mediates file access
and POSIX.1e capabilities.

Crispin

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

Re: AppArmor FAQ

[Joshua Brindle]

Crispin Cowan wrote:
> David Wagner wrote:
>   
>> James Morris  wrote:
>>   
>>     
>>> [...] you can change the behavior of the application and then bypass 
>>> policy entirely by utilizing any mechanism other than direct filesystem 
>>> access: IPC, shared memory, Unix domain sockets, local IP networking, 
>>> remote networking etc.
>>>     
>>>       
>> [...]
>>   
>>     
>>> Just look at their code and their own description of AppArmor.
>>>     
>>>       
>> My gosh, you're right.  What the heck?  With all due respect to the
>> developers of AppArmor, I can't help thinking that that's pretty lame.
>> I think this raises substantial questions about the value of AppArmor.
>> What is the point of having a jail if it leaves gaping holes that
>> malicious code could use to escape?
>>
>> And why isn't this documented clearly, with the implications fully
>> explained?
>>
>> I would like to hear the AppArmor developers defend this design decision.
>>   
>>     
> It was a simplicity trade off at the time, when AppArmor was mostly
> aimed at servers, and there was no HAL or DBUS. Now it is definitely a
> limitation that we are addressing. We are working on a mediation system
> for what kind of IPC a confined process can do
> http://forge.novell.com/pipermail/apparmor-dev/2007-April/000503.html
>
>   
Except servers use IPC and need this access control as well. Without IPC 
and network restrictions you can't protect database servers, ldap 
servers, print servers, ssh agents, virus scanning servers, spam 
scanning servers, etc from attackers with knowledge of how to abuse the IPC.
> When our IPC mediation system is code instead of vapor, it will also
> appear here for review. Meanwhile, AppArmor does not make IPC security
> any worse, confined processes are still subject to the usual Linux IPC
> restrictions. AppArmor actually makes the IPC situation somewhat more
> secure than stock Linux, e.g. normal DBUS deployment can be controlled
> through file access permissions. But we are not claiming AppArmor to be
> an IPC security enhancement, yet.
>   
Without a security interface in DBUS similar to SELinux' apparmor won't 
be able to control who can talk to who across DBUS, only who can connect 
to DBUS directly.

Re: AppArmor FAQ

[Joshua Brindle]

Crispin Cowan wrote:
> David Wagner wrote:
>   
>> James Morris  wrote:
>>   
>>     
>>> [...] you can change the behavior of the application and then bypass 
>>> policy entirely by utilizing any mechanism other than direct filesystem 
>>> access: IPC, shared memory, Unix domain sockets, local IP networking, 
>>> remote networking etc.
>>>     
>>>       
>> [...]
>>   
>>     
>>> Just look at their code and their own description of AppArmor.
>>>     
>>>       
>> My gosh, you're right.  What the heck?  With all due respect to the
>> developers of AppArmor, I can't help thinking that that's pretty lame.
>> I think this raises substantial questions about the value of AppArmor.
>> What is the point of having a jail if it leaves gaping holes that
>> malicious code could use to escape?
>>
>> And why isn't this documented clearly, with the implications fully
>> explained?
>>
>> I would like to hear the AppArmor developers defend this design decision.
>>   
>>     
> It was a simplicity trade off at the time, when AppArmor was mostly
> aimed at servers, and there was no HAL or DBUS. Now it is definitely a
> limitation that we are addressing. We are working on a mediation system
> for what kind of IPC a confined process can do
> http://forge.novell.com/pipermail/apparmor-dev/2007-April/000503.html
>
>   
Also, things like:

    share_mem /usr/bin/firefox r,        # /bin/foo can share memory with /usr/bin/firefox for read only

clearly show that you aren't using native abstractions for IPC. The 
native abstraction for shared memory would be the key used when creating 
the shared memory segment. The same goes for message queues which are 
noticeably missing from the "simplified" IPC model.

This, of course, begs the question of whether you are using native 
abstractions for profiles at all, processes have nothing to do with the 
binary they started from after they've been started. The binary on disk 
could be something entirely different than the process from which it ran.

Re: AppArmor FAQ

[Pavel Machek]

Hi!

> >> Some may infer otherwise from your document.
> >>     
> > Not only that, the implication that secrecy is only useful to
> > intelligence agencies is pretty funny.
> That was not the claim. Rather, that intelligence agencies have a very
> strong need for privacy, and will go to greater lengths to get it,
> including using MLS systems. I contend that while most organizations
> want privacy, they don't want it so badly that they will put up with
> MLS, and so are looking for a more tolerable form of security.
> 
> This is relevant here because information flow is the main advantage of
> labels over pathnames for access control. AppArmor does not attempt to
> manage information flow, allowing it to use pathnames to achieve ease of
> use. If you want information flow control, then by all means use a

As SEEdit shows, you can still have ease-of-use with system capable of
MLS.... so don't try to paint is as "pathnames are neccessary so it is
easy to use".

Just extend SELinux to handle new files.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: AppArmor FAQ

[Pavel Machek]

Hi!

> >> Maybe you'd like to confine the PHP interpreter to limit what it can do.
> >> That might be a good application for something like AppArmor.  You don't
> >> need comprehensive information flow control for that kind of use, and
> >> it would likely just get in the way.
> >
> >SELinux can do this, it's policy-flexible.  You can even simulate a 
> >pathame-based policy language with a consequential loss of control:
> 
> I have no doubt that SELinux can do that, but that has about as much
> relevance to my point as the price of tea in China does.  I can use a
> screwdriver to drive in a nail into my wall, too, if I really wanted to,
> but that doesn't mean toolmakers should stop manufacturing hammers.

Well, we are talking about kernel here, and if screwdrivers work well
enough to drive nails into walls, we'll not allow hammers in.

> My point is that there are some tasks where it's plausible that AppArmor
> might well be a better (easier-to-use) tool for the job.  I'm

If SELinux can do the task, AA people are welcome to port their
userland apps to SELinux to make it user friendly. We do _not_ provide
user friendly services in kernel.

Someone wanted shell inside kernel because it is convenient to
him. Too bad, not going to be merged.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: AppArmor FAQ

[Pavel Machek]

Hi!

> >> I'm not sure if AppArmor can be made good security for the general case,
> >> but it is a model that works in the limited http environment
> >> (eg .htaccess) and is something people can play with and hack on and may
> >> be possible to configure to be very secure.
> >>     
> > Perhaps -- until your httpd is compromised via a buffer overflow or 
> > simply misbehaves due to a software or configuration flaw, then the 
> > assumptions being made about its use of pathnames and their security 
> > properties are out the window.
> >   
> How is it that you think a buffer overflow in httpd could allow an
> attacker to break out of an AppArmor profile? This is exactly what
> AppArmor was designed to do, and without specifics, this is just
> FUD.

No, it is not, I already broke AppArmor once, and it took me less then
one hour.

Give me machine with root shell, and make app armor permit everything
but reading /etc/secret.file. AppArmor is not designed for this, but
if you want to claim your solution works, this looks like a nice test.

Actually, give password to everyone, and see who breaks it first.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: AppArmor FAQ

[david]

On Sat, 9 Jun 2007, Pavel Machek wrote:

> Hi!
>
>>>> I'm not sure if AppArmor can be made good security for the general case,
>>>> but it is a model that works in the limited http environment
>>>> (eg .htaccess) and is something people can play with and hack on and may
>>>> be possible to configure to be very secure.
>>>>
>>> Perhaps -- until your httpd is compromised via a buffer overflow or
>>> simply misbehaves due to a software or configuration flaw, then the
>>> assumptions being made about its use of pathnames and their security
>>> properties are out the window.
>>>
>> How is it that you think a buffer overflow in httpd could allow an
>> attacker to break out of an AppArmor profile? This is exactly what
>> AppArmor was designed to do, and without specifics, this is just
>> FUD.
>
> No, it is not, I already broke AppArmor once, and it took me less then
> one hour.
>
> Give me machine with root shell, and make app armor permit everything
> but reading /etc/secret.file. AppArmor is not designed for this, but
> if you want to claim your solution works, this looks like a nice test.
>
> Actually, give password to everyone, and see who breaks it first.

you admit that AA isn't designed for this and then you set this as the 
test, doesn't that seem unreasonable to you?

SELinux may be designed to protect against a local root user, AA is not.

different tools, different tasks.

David Lang

Re: AppArmor FAQ

[Pavel Machek]

Hi!

> >>>>I'm not sure if AppArmor can be made good security for the general case,
> >>>>but it is a model that works in the limited http environment
> >>>>(eg .htaccess) and is something people can play with and hack on and may
> >>>>be possible to configure to be very secure.
> >>>>
> >>>Perhaps -- until your httpd is compromised via a buffer overflow or
> >>>simply misbehaves due to a software or configuration flaw, then the
> >>>assumptions being made about its use of pathnames and their security
> >>>properties are out the window.
> >>>
> >>How is it that you think a buffer overflow in httpd could allow an
> >>attacker to break out of an AppArmor profile? This is exactly what
> >>AppArmor was designed to do, and without specifics, this is just
> >>FUD.
> >
> >No, it is not, I already broke AppArmor once, and it took me less then
> >one hour.
> >
> >Give me machine with root shell, and make app armor permit everything
> >but reading /etc/secret.file. AppArmor is not designed for this, but
> >if you want to claim your solution works, this looks like a nice test.
> >
> >Actually, give password to everyone, and see who breaks it first.
> 
> you admit that AA isn't designed for this and then you set this as the 
> test, doesn't that seem unreasonable to you?

httpd's run at root priviledge, AFAICT, and Crispin just accused
someone of spreading fud. Exploited httpd is root shell.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: AppArmor FAQ

[david]

On Sun, 10 Jun 2007, Pavel Machek wrote:

>>>>>> I'm not sure if AppArmor can be made good security for the general case,
>>>>>> but it is a model that works in the limited http environment
>>>>>> (eg .htaccess) and is something people can play with and hack on and may
>>>>>> be possible to configure to be very secure.
>>>>>>
>>>>> Perhaps -- until your httpd is compromised via a buffer overflow or
>>>>> simply misbehaves due to a software or configuration flaw, then the
>>>>> assumptions being made about its use of pathnames and their security
>>>>> properties are out the window.
>>>>>
>>>> How is it that you think a buffer overflow in httpd could allow an
>>>> attacker to break out of an AppArmor profile? This is exactly what
>>>> AppArmor was designed to do, and without specifics, this is just
>>>> FUD.
>>>
>>> No, it is not, I already broke AppArmor once, and it took me less then
>>> one hour.
>>>
>>> Give me machine with root shell, and make app armor permit everything
>>> but reading /etc/secret.file. AppArmor is not designed for this, but
>>> if you want to claim your solution works, this looks like a nice test.
>>>
>>> Actually, give password to everyone, and see who breaks it first.
>>
>> you admit that AA isn't designed for this and then you set this as the
>> test, doesn't that seem unreasonable to you?
>
> httpd's run at root priviledge, AFAICT, and Crispin just accused
> someone of spreading fud. Exploited httpd is root shell.

only poorly designed webservers run as root. in general they have not been 
running as root for many years.

however, if you are willing to take a limited shell (root or any other 
user) that's a different story, what would you want the shell to have 
permission to do? would read files in directory A and write files in 
directory B be good enough? or would you want it to be able to execute 
specific commands?

note that at the moment I am not comitting anyone to provide a box for 
such a challange, but I'm interested in what you would consider a suitable 
test.

David Lang