Re: AppArmor FAQ

[Karl MacMillan <kmacmill@redhat.com>]

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



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