linux-kernel - Re: AppArmor FAQ

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f03fgh$2o1$1@taverner.cs.berkeley.edu>
Date:	Tue, 17 Apr 2007 21:51:13 +0000 (UTC)
From:	daw@...berkeley.edu (David Wagner)
To:	linux-kernel@...r.kernel.org
Subject: Re: AppArmor FAQ

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