Add the ability to control mounting and unmounting
The basic form of the rules are.
[audit] [deny] mount [conds]* [device] [ -> [conds] path],
[audit] [deny] remount [conds]* [path],
[audit] [deny] umount [conds]* [path],
[audit] [deny] pivotroot [oldroot=<value>] <path> -> <profile>
remount is just a short cut for mount options=remount
where [conds] can be
fstype=<expr>
options=<expr>
conds follow the extended conditional syntax of allowing either:
* a single value after the equals, which has the same character range as
regular IDS (ie most anything but it can't be terminated with a , (comma)
and if spaces or other characters are needed it can be quoted
eg.
options=foo
options = foo
options="foo bar"
* a list of values after the equals, the list of values is enclosed within
parenthesis () and its has a slightly reduced character set but again
elements can be quoted.
the separation between elements is whitespace and commas.
eg.
options=(foo bar)
options=(foo, bar)
options=(foo , bar)
options=(foo,bar)
The rules are flexible and follow a similar pattern as network, capability,
etc.
mount, # allow all mounts, but not umount or pivotroot
mount fstype=procfs, # allow mounting procfs anywhere
mount options=(bind, ro) /foo -> /bar, # readonly bind mount
mount /dev/sda -> /mnt,
mount /dev/sd** -> /mnt/**,
mount fstype=overlayfs options=(rw,upperdir=/tmp/upper/,lowerdir=/) overlay -> /mnt/
umount,
umount /m*,
Currently variables and regexs are are supported on the device and mount
point. ie.
mount <devince> -> <mount point>,
Regexes are supported in fstype and options. The options have a further
caveat that regexs only work if the option is fs specific option.
eg. options=(upperdir=/tmp/*,lowerdir=/)
regex's will not currently work against the standard options like ro, rw
nosuid
Conditionals (fstype) can only be applied to the device (source) at this
time and will be disregarded in situations where the mount is manipulating
an existing mount (bind, remount).
Options can be specified multiple times
mount option=rw option=(nosuid,upperdir=/foo),
and will be combined together into a single set of values
The ordering of the standard mount options (rw,ro, ...) does not matter
but the ordering of fs specific options does.
Specifying that the value of a particular option does not matter can be
acheived by providing both the positive and negative forms of and option
option=(rw,ro) options=(suid,nosuid)
For the fs specific options specifying that a particular value does not
matter is achieve using a regex with alternations.
Improvements to the syntax and order restrictions are planned for the
future.
Signed-off-by: John Johansen <john.johansen@canonical.com>
Add the optional 'file' keyword to the language/grammer. The main reason
for doing this is to support false token injection. Which is needed
to move towards the parser being broken out into an api that can be
used to parse individual rule types, separate from parsing the whole file.
Since we are adding the token to the grammar expose it to userspace with
the 'file' keyword. While not needed it helps bring consistency, as all
the other rule types start with a keyword (capability, network, rlimit, ...).
Also allow the bare keyword to be used to represent allowing all file
operations, just as with network and capability. Domain transitions are
defaulted to ix. Thus
file,
is equivalent to
/** rwlkmix,
Signed-off-by: John Johansen <john.johansen@canonical.com>
Acked-by: Kees Cook <kees@ubuntu.com>
The ability to set capabilities from a profile has been removed from the
kernel for several releases. Remove it from the parser as well.
Signed-off-by: John Johansen <john.johansen@canonical.com>
Acked-by: Kees Cook <kees@ubuntu.com>
Allow the capability rule to be bare to represent all capabilities similar
to how network, and other rule types work.
capability,
Signed-off-by: John Johansen <john.johansen@canonical.com>
Acked-by: Kees Cook <kees@ubuntu.com>
create the generated_* directories themselves if they don't exist before
running the script to generate them.
Also modify the default invocation of prove to add -f, which reports the
details of failing test cases.
'[[:alpha:]][[:alnum:]_]*' (i.e. a single alpha followed by any number
of alphanumerics or underscores). Unfortunately, the code that expends
variables inside a profile does not match this, it incorrectly matched
'([[:alpha:]]|_)+' (one or more alphas or underscores). This patch
corrects the behavior there as well as synchronizing the expected
variable names in the apparmor.d manpage and apparmor.vim syntax file.
It also adds unit tests and testcases to verify the behavior.
Signed-off-by: Steve Beattie <sbeattie@ubuntu.com>
Description: the Ubuntu buildds do not have the AppArmor securityfs mounted, so
the cache tests fail. This patch skips these tests if the introspection
directory is not mounted, but runs them if it is. This should allow testing of
local builds while still allowing builds on the official buildds.
Acked-By: Steve Beattie <sbeattie@ubuntu.com> - both Ubuntu and
OpenSUSE were carrying patches that disabled the caching test,
though OpenSUSE's disabled it completely rather than checking. The
parser builds need to complete even when the kernel it's building on
doesn't support AppArmor or all the extensions that the parser needs
at runtime.
"SubDomain" in some way. This leaves only "subdomain.conf" and the
function names internally.
Additionally, I added a "make check" rule to the utils/Makefile to do a
simple "perl -c" sanity check just for good measure.
Currently apparmor provides the unsafe keyword to indicate an xtransition
is not scrubbing its environment variables. This can be used to be
explicit about which transition are unsafe instead of relying on people
remembering which of px Px is safe or unsafe.
Add the orthogonal keyword safe to allow specifying a transition is
safe.
Signed-off-by: John Johansen <john.johansen@canonical.com>
x Permissions when specified as a the start of the rule had a differnt
meaning than when they appeared at the tail of a rule.
Specifically px,cx,ux were not treated as unsafe when they appeared at
the start of the rule.
px /foo,
instead of at the tail of the rule
/foo px,
the keyword unsafe had to be used to force the rule to cause the x transitio
to be its unsafe variant.
Fix leading permissions so that they are consistent with file rules that
use trailing permissions.
Signed-off-by: John Johansen <john.johansen@canonical.com>
Test the leading permission form of an xrule against its trailing permission
form, to verify that they are generating the same xtransition and thus
don't conflict (assumes xtransition conflict checking is working).
eg.
px /foo,
/foo px,
should generate the same rule and thus not result in any conflicts
Signed-off-by: John Johansen <john.johansen@canonical.com>
All the combiniation of xtransition conflics where not well represented in
the regression test suite. Instead of relying on multiple static test
files, automatically generate all possible conflicts.
Signed-off-by: John Johansen <john.johansen@canonical.com>
Several of the x-trans tests where failing because of the include file was
bad. This kept the test from testing what it was supposed as the test
was expected to fail. Thus hidding a bug :(
Signed-off-by: John Johansen <john.johansen@canonical.com>
clean up profile parsing by merging profile and :namespace:profile parsing
into a single rule.
This also fixes a bug where the profile keyword was not allowed to proceed
profiles with a namespace declaration.
Signed-off-by: John Johansen <john.johansen@canonical.com>
Acked-By: Steve Beattie <sbeattie@ubuntu.com>
script and add an additional sleep before the parser invocation that
generates the cache file for the first time, to avoid failures in the
"Profiles are cached when requested:" test on ext3 and other filesystems
without fine-grained enough timestamps.
* a non-include related syntax error (errors/modefail.sd)
* multiple successful includes followed by a failed include
(errors/multi_include.sd)
It also fixes two issues with the parser's line counting:
* the count began at 0 (demonstrated by the first testcase's error
being reporting on one line less than it should be), and
* an extra line increment when includes were detected (demonstrated
by the second testcase's error being reported at a line beyond the
correct linenumber.
The existing testcases did not catch these because they were all
based on the first include in the file failing and so the start of
the count from 0 counteracted the extra counted line.
Change_profile was broken so that it couldn't parse expressions that
weren't path based or started with a variable. Furthermore if the name
held any expressions it was not hanlded correctly, as it was being passed
directly to dfa conversion without going through glob -> pcre conversion.
