There is an integer overflow when comparing priorities when cmp is
used because it uses subtraction to find lessthan, equal, and greater
than in one operation.
But INT_MAX and INT_MIN are being used by priorities and this results
in INT_MAX - INT_MIN and INT_MIN - INT_MAX which are both overflows
causing an incorrect comparison result and selection of the wrong
rule permission.
Closes: https://gitlab.com/apparmor/apparmor/-/issues/452
Fixes: e3fca60d1 ("parser: add the ability to specify a priority prefix to rules")
Signed-off-by: John Johansen <john.johansen@canonical.com>
Move from using and int for permissions bit mask to a perms_t type.
Also move any perms mask that uses the name mode to perms to avoid
confusing it with other uses of mode.
Signed-off-by: John Johansen <john.johansen@canonical.com>
The parser currently is still using the old permission layout, the kernel
uses a newer layout that allows for more permission bits. The newer
newer permission layout is needed by the library to query the kernel,
however that causes some of the permission bits to be redefined.
Rename the permission bits that cause redefination warnings to use
AA_OLD_MAY_XXX
Signed-off-by: John Johansen <john.johansen@canonical.com>
Acked-by: Tyler Hicks <tyhicks@canonical.com>
It was never used, never supported, and we are doing it differently now.
Signed-off-by: John Johansen <john.johansen@canonical.com>
Acked-by: Seth Arnold <seth.arnold@canonical.com>
Now that the parser links against libapparmor, it makes sense to move
all public permission types and flags to libapparmor's apparmor.h. This
prevents duplication across header files for the parser and libapparmor.
Additionally, this patch breaks the connection between
AA_DBUS_{SEND,RECEIVE,BIND} and AA_MAY_{WRITE,READ,BIND} by using raw
values when defining the AA_DBUS_{SEND,RECEIVE,BIND} macros. This makes
sense because the two sets of permission flags are from two distinctly
different mediation types (AA_CLASS_DBUS and AA_CLASS_FILE). While it is
nice that they share some of the same values, the macros don't need to
be linked together. In other words, when you're creating a D-Bus rule,
it would be incorrect to use permission flags from the AA_CLASS_FILE
type.
The change mentioned above allows the AA_MAY_{WRITE,READ,BIND} macros
to be removed from public-facing apparmor.h header.
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Acked-by: Seth Arnold <seth.arnold@canonical.com>
Allows for the policy writer to grant permission to eavesdrop on the
specified bus. Some example rules for granting the eavesdrop permission
are:
# Grant send, receive, bind, and eavesdrop
dbus,
# Grant send, receive, bind, and eavesdrop on the session bus
dbus bus=session,
# Grant send and eavesdrop on the system bus
dbus (send eavesdrop) bus=system,
# Grant eavesdrop on any bus
dbus eavesdrop,
Eavesdropping rules can contain the bus conditional. Any other
conditionals are not compatible with eavesdropping rules and the parser
will return an error.
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Acked-by: Seth Arnold <seth.arnold@canonical.com>
This patch implements the parsing of DBus rules.
It attempts to catch all corner cases, such as specifying a bind
permission with an interface conditional or specifying a subject name
conditional and a peer name conditional in the same rule.
It introduces the concept of conditional lists to the lexer and parser
in order to handle 'peer=(label=/usr/bin/foo name=com.foo.bar)', since
the existing list support in the lexer only supports a list of values.
The DBus rules are encoded as follows:
bus,name<bind_perm>,peer_label,path,interface,member<rw_perms>
Bind rules stop matching at name<bind_perm>. Note that name is used for
the subject name in bind rules and the peer name in rw rules. The
function new_dbus_entry() is what does the proper sanitization to make
sure that if a name conditional is specified, that it is the subject
name in the case of a bind rule or that it is the peer name in the case
of a rw rule.
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Acked-by: Seth Arnold <seth.arnold@canonical.com>
Bug #963756
The kernel has an extended test for change_profile when used with
onexec, that allows it to only work against set executables.
The parser is not correctly mapping change_profile for this test
update the mapping so change_onexec will work when confined.
Note: the parser does not currently support the extended syntax
that the kernel test allows for, this just enables it to work
for the generic case.
Signed-off-by: John Johansen <john.johansen@canonical.com>
The in x intersection consistency test for minimization was failing because
it was screening off the AA_MAY_EXEC permission before passing the exec
information to the consistency test fn. This resulted in the consistency
test fn not testing the consistency because it treated the permission set
as not having x permissions.
Signed-off-by: John Johansen <john.johansen@canonical.com>
Acked-By: Steve Beattie <sbeattie@ubuntu.com>
Output a better failure message when a conflict of x permissions cause
policy compilation to fail. We don't have enough information available
to output which rules during the dfa compilation so just improve the
message to let people know that it means there are conflicting x modifiers
in the rules.
Signed-off-by: John Johansen <john.johansen@canonical.com>
The is_merged_x_consistend macro was incorrect in that is tested for
USER_EXEC_TYPE to determine if there was an x transition. This fails
for unconfined execs so an unconfined exec would not correctly conflict
with another exec type.
The dfa match flag table for xtransitions was not large enough and not
indexed properly for pux, and cux transitions. The index calculation did
not take into account the pux flag so that pux and px aliased to the same
location and cux and cx aliased to the same location.
This would result in the first rule being processed defining what the
transition type was for all following rules of the type following. So
if a px transition was processed first all pux, transitions in the profile
would be treated pux.
Signed-off-by: John Johansen <john.johansen@canonical.com>
This (updated) patch to trunk adds support for Px and Ux (toggle
bprm_secure on exec) in the parser, As requested, lowercase p and u
corresponds to an unfiltered environmnet on exec, uppercase will filter
the environment. It applies after the 'm' patch.
As a side effect, I tried to reduce the use of hardcoded characters in
the debugging statements -- there are still a few warnings that have
hard coded letters in them; not sure I can fix them all.
This version issues a warning for every unsafe ux and issues a single
warning for the first 'R', 'W', 'X', 'L', and 'I' it encounters,
except when the "-q" or "--quiet" flag , "--remove" profile flag, or
"-N" report names flags are passed. Unfortunately, it made the logic
somewhat more convoluted. Wordsmithing improvements welcome.
This (updated) patch to trunk adds the m flag to the parser language. The
m flag explicitly does -not- conflict with px, ux, or ix.
It does not add exec mmap as implicit to inherited execs, as it was
asserted that the module should do this.
I have not fixed up the testcases to match.
