Re: [AppArmor 00/41] AppArmor security module overview

["Rob Meijer" <capibara@xs4all.nl>]

I've posted on the subject before, and as noone seemed to truely relate
to the concept I concequently dropped my effords, but as you seem to be half
a step in the general right direction, this may be a good time to bring
it up again.

If instead of 'least privilege' and fat profiles, you would opt for 'least
authority' and (potentialy) thin profiles, this would make the whole also
usable for systems initialy designed with security in mind.
To accomplish such a thing I proposed that the non 'at' family of calls
for filesystems should be considdered to be priviledged operations (within
a least authority context), and the 'at' family of operations should have
invocations with uptree path tokens also be considdered priviledged
(within a least authority context). The non uptree invocations of the 'at'
family
should be considdered unpriviledged, and should thus always be allowed
seperately from any profile.

With this distinction implemented, you could than potentialy use thin
profiles and dynamicly exchange authority by passing along directory
file handles when needed.

Where with the 'least priviledge' approach the profile would need to grant
the each priviledge the application might need, but when you would be able
to use both file handles, socket handles and directory handles as tokens
of authorization that can be comunicated seperately and freely, without
being stopped from being used by least priviledge profiles, the profiles
needed will start out much thiner, and will dynamicly expand to just a
limited subset of the fat least priviledge profile.

I believe that being able to be able to distinguish between the
the least authority (no uptree) usage of open file/dir/socket handles and
other operations is essential. If a profile blocks a program from using
these open file/dir/socket handles in a way not violating least authority
(that is no uptree tokens in at family calls), this would be a major
design flaw.

Rob


On Thu, April 12, 2007 11:08, jjohansen@suse.de wrote:

> AppArmor's Overall Design
> =========================
>
> AppArmor protects systems from vulnerable software by confining
> processes, giving them "least privilege" access to the system's
> resources: with least privilege, processes are allowed exactly what they
> need, nothing more, and nothing less. Systems are thus protected from
> bugs in applications that would lead to privilege escalation, such as
> remote system access because of a buffer overflow in a web server, etc.
>
> AppArmor does this by defining application profiles which list allowed
> accesses, and assigning those profiles to processes. AppArmor does *not*
> require the user to confine all processes on the system.  Rather, you
> need to provide AppArmor profiles for every process that is potentially
> subject to manipulation by the attacker. For instance, to defend against
> network attack, confine all process that access the network.
>
> The corollary to this is that attacks against AppArmor that start with
> "assume some unconfined process does ..." are outside the AppArmor
> threat model. Any process that might do something malicious to an
> AppArmor system should be confined by an AppArmor profile.
>
> The kernel manages many different kinds of resources.  AppArmor
> currently controls access to two key resources among them: files, and
> POSIX Capabilities.  (Additional protection for things like rlimits,
> interprocess communication, and network access are being worked on, and
> are expected to become available in a future version.)
>
>
> File Access Control
> -------------------
>
> Application profiles control file access by pathname: each profile
> contains a list of fully qualified pathnames (potentially containing
> globbing) and associated access modes: read (r), write (w), different
> kinds of execute (ix, Px, px, Ux, ux), create hard-link (l), and memory
> map for execution (m).
>
> For example, the following two rules permit read access to any file
> below /srv/www/htdocs/**.html, and memory map for execution (m), execute
> inheriting the current profile (ix), and read (r) access to
> /usr/sbin/suexec2:
>
>     /srv/www/htdocs/**.html r,
>     /usr/sbin/suexec2 mixr,


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