Add support for specifying the path prefix used when attach disconnected
is specified. The kernel supports prepending a different value than
/ when a path is disconnected. Expose through a profile flag.
Signed-off-by: John Johansen <john.johansen@canonical.com>
Currently only file rules get merged. Finish adding basic support
for rule merging and make the default the behavior to dedup
merge rules that are exact matches.
Signed-off-by: John Johansen <john.johansen@canonical.com>
In preparation for file rules and rule duplication removal add
flags to rule_t with the first flag indicating if the rule is
deleted.
We do this instead of actually deleting the rule so we can hold
on to the rule for debug and printing output in the future.
Signed-off-by: John Johansen <john.johansen@canonical.com>
This patch fixes the unit test memory leaks found
by intrigeri using AddressSanitizer in the following email thread:
https://lists.ubuntu.com/archives/apparmor/2015-August/008491.html
Signed-off-by: Steve Beattie <steve@nxnw.org>
Acked-by: Seth Arnold <seth.arnold@canonical.com>
When @{profile_name} is used within a rule matching expression any
aare expressions should be matched literally and not be interpreted as
aare.
That is
profile /foo/** { }
needs /foo/** to expand into a regular expression for its attachment
but, /foo/** is also the profiles literal name. And when trying to
match @{profile_name} in a rule, eg.
ptrace @{profile_name},
the variable needs to be expaned to
ptrace /foo/\*\*,
not
ptrace /foo/**,
that is currently happening.
BugLink: http://bugs.launchpad.net/bugs/1317555
equality tests by
Tyler Hicks <tyhicks@canonical.com>
Signed-off-by: John Johansen <john.johansen@canonical.com>
Acked-by: Steve Beattie <steve@nxnw.org>
The @{profile_name} is incorrectly expanded as a fully qualified path
including its namespace if one was specified in the profile declaration.
ie.
profile :ns://a {
ptrace @{profile_name},
# expands to
# ptrace :ns://a,
}
This is wrong however because within a profile if a rule refers
to a namespace it will be wrt a sub-namespace. That is in the above
example the ptrace rule is refering to a profile in a subnamespace
"ns".
Or from the current profile declaration scope
:ns//ns://a
Instead @{profile_name} should expand into the hname (hierarchical name),
which is the profile hierarchy specification within the namespace the
profile is part of.
In this case
a
or for a child profile case
profile :ns://a {
profile b {
ptrace @{profile_name},
}
}
the hname expansion would be
a//b
Signed-off-by: John Johansen <john.johansen@canonical.com>
Acked-by: Steve Beattie <steve@nxnw.org>
allow
@{FOO}=bar
/foo@{FOO} { }
to be expanded into
/foobar { }
and
@{FOO}=bar baz
/foo@{FOO} { }
to be expanded into
/foo{bar,baz} { }
which is used as a regular expression for attachment purposes
Further allow variable expansion in attachment specifications
profile foo /foo@{FOO} { }
profile name (if begun with profile keyword) and attachments to begin
with a variable
profile @{FOO} { }
profile /foo @{FOO} { }
profile @{FOO} @{BAR} {}
hats
^@{FOO}
hat @{FOO}
and for subprofiles as well
Signed-off-by: John Johansen <john.johansen@canonical.com>
Acked-by: Steve Beattie <steve@nxnw.org>
link rules with a variable in the link target, eg.
link /foo -> @{var},
do not currently have the variable expanded
Signed-off-by: John Johansen <john.johansen@canonical.com>
Acked-by: Tyler Hicks <tyhicks@canonical.com>
Acked-by: Seth Arnold <seth.arnold@canonical.com>
Signed-off-by: John Johansen <john.johansen@canonical.com>
[tyhicks: Forward ported patch to trunk]
[tyhicks: remove commented out code]
[tyhicks: fix use after free]
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
table
This patch adds the creation of an implicit set variable
@{profile_name} for use within policy. It expands to:
- a given profile name if specified; e.g. for
'profile flappy_bird /some/pattern/match* { [...] }'
@{profile_name} would expand to 'flappy_bird'
- if no given name, the match pattern; e.g. for
'/usr/bin/doge_bird { [...] }'
@{profile_name} would expand to '/usr/bin/doge_bird'
- hats and child profiles will include the fully qualified name; e.g.
the 'doge' hat in the /usr/bin/flappy_bird profile would cause
@{profile_name} to expand to '/usr/bin/flappy_bird//doge' within the
'doge' hat, and '/usr/bin/flappy_bird' outside of it in the profile.
There are some parsing tests added, but more tests are needed to verify
that expansion occurs properly (I've verified manually using parser
dumps of the added tests, but automated checks are needed).
The @{profile_name} variable is expected to be most useful in the
context of signal and ptrace rules (e.g. for specifying that an app
can send itself signals).
Signed-off-by: Steve Beattie <steve@nxnw.org>
Acked-by: Seth Arnold <seth.arnold@canonical.com>
This will simplify add new features as most of the code can reside in
its own class. There are still things to improve but its a start.
Signed-off-by: John Johansen <john.johansen@canonical.com>
Acked-by: Steve Beattie <steve@nxnw.org>
As noted by Seth Arnold, in expand_by_alternations() if our set
variable has at least one value, then we're going to rewrite the entry,
so rather than sprinkle the free()s near where the reallocation occurs,
use one free() once we're guaranteed to need to do so.
Signed-off-by: Steve Beattie <steve@nxnw.org>
Acked-by: John Johansen <john.johansen@canonical.com>
As suggested by Seth Arnold, we can use string::find_last_not_of()
instead of using C++'s hideous reverse iterators.
Signed-off-by: Steve Beattie <steve@nxnw.org>
Acked-by: John Johansen <john.johansen@canonical.com>
With the previous patch to switch to using alternations for variable
expansion, the clone_and_chain set of functions are no longer needed
and no longer need to be passed around. This patch removes them.
(I kept this patch separate to keep the previous patch smaller and more
easily reviewed.)
Signed-off-by: Steve Beattie <steve@nxnw.org>
Acked-by: Seth Arnold <seth.arnold@canonical.com>
This patch converts the parser's variable expansion from adding new
entries for each additional variable value to incorporating an
alternation that includes all the values for the variable; e.g. given:
@{BINS}=/bin /usr/bin /sbin /usr/sbin
@{BINS}/binary ix,
rather than expanding to exntries for
/bin/binary
/usr/bin/binary
/sbin/binary
/usr/sbin/binary
one entry would remain that looks like:
{/bin,/usr/bin,/sbin,/usr/sbin}/binary
One complication with this patch is that we try to prevent mistakes for
our users with variable expansion around '/'s; it's common for people to
write profiles that contain things like:
@{BAR}=/bingo/*/ /bango/
/foo/@{BAR}/baz
We already have a post-processing step that walks entries looking
for multiple sequences of '/'s and filters them into single
'/' which worked when creating new entries for each variable
expansion. Converting to alternation expansion breaks this filtering,
so code is added that removes leading and trailing slashes in variable
values in the expansion if the character immediately preceding or
following the variable is also a slash.
The intent behind this is to reduce the amount of memory allocations
and structure walking that needed to occur in when converting from the
entry strings to the back end nodes. Examples with real world profiles
showed performance improvements ranging from 2.5% to 10%. However,
because the back end operations are sensitive to the front end inputs,
it is possible for worse results to occur; for example, it takes the
simple_tests/vars/vars_stress_0[123].sd tests significantly longer to
complete after this patch is applied (vars_stress_03.sd in particular
takes ~23 times longer). An initial analysis of profiling output in
this negative case looks like it causes the tree simplification in
the back end to do more work for unknown reasons.
On the other hand, the test simple_tests/vars/vars_dbus_9.sd
(introduced in "[patch 09/12] parser: more dbus variable testcases")
takes ~1 sec to complete on my laptop before this patch, and roughly
0.01s with this patch applied.
(One option would be to keep the "expand entries" approach as an
alternative, but I couldn't come up with a good heuristic for when
to use it instead.)
Signed-off-by: Steve Beattie <steve@nxnw.org>
Acked-by: Seth Arnold <seth.arnold@canonical.com>
This patch addresses a bunch of the compiler string conversion warnings
that were introduced with the C++-ification patch.
Signed-off-by: Steve Beattie <steve@nxnw.org>
Acked-by: Tyler Hicks <tyhicks@canonical.com>
Convert the codomain to a class, and the policy lists that store
codomains to stl containers instead of glibc twalk.
Signed-off-by: John Johansen <john.johansen@canonical.com>
[tyhicks: Merge with dbus changes and process_file_entries() cleanup]
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Acked-by: Steve Beattie <steve@nxnw.org>
This conversion is nothing more than what is required to get it to
compile. Further improvements will come as the code is refactored.
Unfortunately due to C++ not supporting designated initializers, the auto
generation of af names needed to be reworked, and "netlink" and "unix"
domain socket keywords leaked in. Since these where going to be added in
separate patches I have not bothered to do the extra work to replace them
with a temporary place holder.
Signed-off-by: John Johansen <john.johansen@canonical.com>
[tyhicks: merged with dbus changes and memory leak fixes]
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Acked-by: Seth Arnold <seth.arnold@canonical.com>
Acked-by: Steve Beattie <steve@nxnw.org>
Bug: https://bugs.launchpad.net/bugs/1218099
This patch adds support for expanding variables with dbus rules.
Specifically, they can expanded within the bus, name, path, member,
interface, and peer label fields.
Parser test cases and regression test cases are added as well.
Patch history:
v1: initial version of patch
v2: add equality.sh tests to verify that the results of using
variable expansion is the same as what should be equivalent rules
Signed-off-by: Steve Beattie <sbeattie@ubuntu.com>
Acked-by: Tyler Hicks <tyhicks@canonical.com>
Acked-by: Seth Arnold <seth.arnold@canonical.com>
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>
This is a rather large rearrangement of how a subset of the parser global
variables are defined. Right now, there are unit tests built without
linking against parser_main.c. As a result, none of the globals defined in
parser_main.c could be used in the code that is built for unit tests
(misc, regex, symtab, variable). To get a clean build, either stubs needed
to be added to "#ifdef UNIT_TEST" blocks in each .c file, or we had to
depend on link-time optimizations that would throw out the unused routines.
First, this is a problem because all the compile-time warnings had to be
explicitly silenced, so reviewing the build logs becomes difficult on
failures, and we can potentially (in really unlucky situations) test
something that isn't actually part of the "real" parser.
Second, not all compilers will allow this kind of linking (e.g. mips gcc),
and the missing symbols at link time will fail the entire build even though
they're technically not needed.
To solve all of this, I've moved all of the global variables used in lex,
yacc, and main to parser_common.c, and adjusted the .h files. On top of
this, I made sure to fully link the tst builds so all symbols are resolved
(including aare lib) and removedonly tst build-log silencing (for now,
deferring to another future patchset to consolidate the build silencing).
Signed-off-by: Kees Cook <kees.cook@canonical.com>
'[[: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>
