Signed-off-by: NJohn Johansen <john.johansen@canonical.com>

The cross check permission helper macros will help simplify code
that does cross task permission checks like ptrace.
Signed-off-by: NJohn Johansen <john.johansen@canonical.com>

Signed-off-by: NJohn Johansen <john.johansen@canonical.com>

Signed-off-by: NJohn Johansen <john.johansen@canonical.com>

Signed-off-by: NJohn Johansen <john.johansen@canonical.com>

Signed-off-by: NJohn Johansen <john.johansen@canonical.com>

Begin the actual switch to using domain labels by storing them on
the context and converting the label to a singular profile where
possible.
Signed-off-by: NJohn Johansen <john.johansen@canonical.com>

Begin moving apparmor to using broader domain labels, that will allow
run time computation of domain type splitting via "stacking" of
profiles into a domain label vec.
Signed-off-by: NJohn Johansen <john.johansen@canonical.com>

Instead of running file revalidation lazily when read/write are called
copy selinux and revalidate the file table on exec. This avoids
extra mediation overhead in read/write and also prevents file handles
being passed through to a grand child unchecked.
Signed-off-by: NJohn Johansen <john.johansen@canonical.com>

Signed-off-by: NJohn Johansen <john.johansen@canonical.com>

Instead of passing multiple booleans consolidate on a single flags
field.
Signed-off-by: NJohn Johansen <john.johansen@canonical.com>

Remove the partially implemented code, until this can be properly
implemented.
Signed-off-by: NJohn Johansen <john.johansen@canonical.com>

Signed-off-by: NJohn Johansen <john.johansen@canonical.com>

The profile names are the same, leverage this.
Signed-off-by: NJohn Johansen <john.johansen@canonical.com>

There are still a few places where profile replacement fails to update
and a stale profile is used for mediation. Fix this by moving to
accessing the current label through a critical section that will
always ensure mediation is using the current label regardless of
whether the tasks cred has been updated or not.
Signed-off-by: NJohn Johansen <john.johansen@canonical.com>

There is no reason to have the small stubs that don't use domain
private functions in domain.c, instead move them to lsm.c and make
them static.
Signed-off-by: NJohn Johansen <john.johansen@canonical.com>

The ns name being displayed should go through an ns view lookup.
Signed-off-by: NJohn Johansen <john.johansen@canonical.com>

The data being queried isn't always the current profile and a lookup
relative to the current profile should be done.
Signed-off-by: NJohn Johansen <john.johansen@canonical.com>

The namespace being passed into the replace/remove profiles fns() is
not the view, but the namespace specified by the inode from the
file hook (if present) or the loading tasks ns, if accessing the
top level virtualized load/replace file interface.
Signed-off-by: NJohn Johansen <john.johansen@canonical.com>

Currently lookups are restricted to a single ns component in the
path. However when namespaces are allowed to have separate views, and
scopes this will not be sufficient, as it will be possible to have
a multiple component ns path in scope.

Add some ns lookup fns() to allow this and use them.
Signed-off-by: NJohn Johansen <john.johansen@canonical.com>

Signed-off-by: NJohn Johansen <john.johansen@canonical.com>

Signed-off-by: NJohn Johansen <john.johansen@canonical.com>

Allow userspace to query a profile about permissions, through the
transaction interface that is already used to allow userspace to
query about key,value data.
Signed-off-by: NJohn Johansen <john.johansen@canonical.com>

Signed-off-by: NJohn Johansen <john.johansen@canonical.com>

Signed-off-by: NJohn Johansen <john.johansen@canonical.com>

Signed-off-by: NJohn Johansen <john.johansen@canonical.com>

The simple_transaction interface is slow. It requires 4 syscalls
(open, write, read, close) per query and shares a single lock for each
queries.

So replace its use with a compatible in multi_transaction interface.
It allows for a faster 2 syscall pattern per query. After an initial
open, an arbitrary number of writes and reads can be issued. Each
write will reset the query with new data that can be read. Reads do
not clear the data, and can be issued multiple times, and used with
seek, until a new write is performed which will reset the data
available and the seek position.

Note: this keeps the single lock design, if needed moving to a per
file lock will have to come later.
Signed-off-by: NJohn Johansen <john.johansen@canonical.com>

gsettings mediation needs to be able to determine if apparmor supports
label data queries. A label data query can be done to test for support
but its failure is indistinguishable from other failures, making it an
unreliable indicator.

Fix by making support of label data queries available as a flag in the
apparmorfs features dir tree.
Signed-off-by: NJohn Johansen <john.johansen@canonical.com>

When setting up namespaces for containers its easier for them to use
an fs interface to create the namespace for the containers
policy. Allow mkdir/rmdir under the policy/namespaces/ dir to be used
to create and remove namespaces.

BugLink: http://bugs.launchpad.net/bugs/1611078Signed-off-by: NJohn Johansen <john.johansen@canonical.com>

Add a policy revision file to find the current revision of a ns's policy.
There is a revision file per ns, as well as a virtualized global revision
file in the base apparmor fs directory. The global revision file when
opened will provide the revision of the opening task namespace.

The revision file can be waited on via select/poll to detect apparmor
policy changes from the last read revision of the opened file. This
means that the revision file must be read after the select/poll other
wise update data will remain ready for reading.
Signed-off-by: NJohn Johansen <john.johansen@canonical.com>

Signed-off-by: NJohn Johansen <john.johansen@canonical.com>

Signed-off-by: NJohn Johansen <john.johansen@canonical.com>

Signed-off-by: NJohn Johansen <john.johansen@canonical.com>

Virtualize the apparmor policy/ directory so that the current
namespace affects what part of policy is seen. To do this convert to
using apparmorfs for policy namespace files and setup a magic symlink
in the securityfs apparmor dir to access those files.
Signed-off-by: NJohn Johansen <john.johansen@canonical.com>
Reviewed-by: NSeth Arnold <seth.arnold@canonical.com>
Reviewed-by: NKees Cook <keescook@chromium.org>

Signed-off-by: NJohn Johansen <john.johansen@canonical.com>
Reviewed-by: NSeth Arnold <seth.arnold@canonical.com>
Reviewed-by: NKees Cook <keescook@chromium.org>

prefixes are used for fns/data that are not static to apparmorfs.c
with the prefixes being
  aafs   - special magic apparmorfs for policy namespace data
  aa_sfs - for fns/data that go into securityfs
  aa_fs  - for fns/data that may be used in the either of aafs or
           securityfs
Signed-off-by: NJohn Johansen <john.johansen@canonical.com>
Reviewed-by: NSeth Arnold <seth.arnold@canonical.com>
Reviewed-by: NKees Cook <keescook@chromium.org>

AppArmor policy needs to be able to be resolved based on the policy
namespace a task is confined by. Add a base apparmorfs filesystem that
(like nsfs) will exist as a kern mount and be accessed via jump_link
through a securityfs file.

Setup the base apparmorfs fns and data, but don't use it yet.
Signed-off-by: NJohn Johansen <john.johansen@canonical.com>
Reviewed-by: NSeth Arnold <seth.arnold@canonical.com>
Reviewed-by: NKees Cook <keescook@chromium.org>

Signed-off-by: NJohn Johansen <john.johansen@canonical.com>
Reviewed-by: NSeth Arnold <seth.arnold@canonical.com>
Reviewed-by: NKees Cook <keescook@chromium.org>

Signed-off-by: NJohn Johansen <john.johansen@canonical.com>
Reviewed-by: NSeth Arnold <seth.arnold@canonical.com>
Reviewed-by: NKees Cook <keescook@chromium.org>

The loaddata sets cover more than just a single profile and should
be tracked at the ns level. Move the load data files under the namespace
and reference the files from the profiles via a symlink.
Signed-off-by: NJohn Johansen <john.johansen@canonical.com>
Reviewed-by: NSeth Arnold <seth.arnold@canonical.com>
Reviewed-by: NKees Cook <keescook@chromium.org>