Add apparmor support module #188
Conversation
This patch adds a new set of files, mimicking the xxx-support pattern used for other changes, that to some extent abstracts the use of apparmor in snap-confine. Even when snap-confine is not compiled with apparmor support the same APIs are available and gracefully degrade to no-ops. As a small extension, snap confine can now know if it is confined (e.g. a development version running in a random directory is not confined) and will no longer crash when changing hats via aa_change_hat(). The patch doesn't yet change any of the tree to use the new functions. This will be done in the next commit. Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
Unconfined processes get "unconfined", not an empty label. Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
| SC_AA_ENFORCE = 1, | ||
| // The enforcement mode is "complain" | ||
| SC_AA_COMPLAIN, | ||
| }; |
There was a problem hiding this comment.
There is a new'ish mode (as of the 16.04 kernel), called "mixed". It means that two or more AppArmor profiles are stacked together but not all of their enforcement modes are the same. The mode string returned from aa_getcon() is "mixed".
There was a problem hiding this comment.
Thanks, I'll update the code to handle this as well.
| char *mode = NULL; // mode cannot be free'd | ||
| if (aa_getcon(&label, &mode) < 0) { | ||
| die("cannot query current apparmor profile"); | ||
| } |
There was a problem hiding this comment.
This misses the situation where AppArmor support is compiled into snap-confine but AppArmor has been explicitly disabled by passing "apparmor=0" on the kernel command line. aa_getcon() will return -1 with errno set to EINVAL in this condition but that errno unfortunately overlaps with some other conditions.
The definitive way to see if AppArmor is enabled is aa_is_enabled(). You should call it first and, if it returns 1, proceed to calling aa_getcon() to check if snap-confine is confined. See the aa_is_enabled() man page for details.
There was a problem hiding this comment.
+1 Thanks for this feedback. I'll do this.
| apparmor->mode = SC_AA_ENFORCE; | ||
| } else { | ||
| apparmor->mode = SC_AA_INVALID; | ||
| } |
There was a problem hiding this comment.
You'll want to check for "mixed" mode here. I've left a more descriptive review comment in the accompanying header file.
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
This patch changes the apparmor support initialization routine to first call aa_is_enabled(). The rest of the code is tweaked for readability. Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
This patch adds a new set of files, mimicking the xxx-support pattern
used for other changes, that so some extent abstracts the use of
apparmor in snap-confine.
Even when snap-confine is not compiled with apparmor support the same
APIs are available and gracefully degrade to no-ops.
As a small extension, snap confine can now know if it is confined (e.g.
a development version running in a random directory is not confined) and
will no longer crash when changing hats via aa_change_hat().
The patch doesn't yet change any of the tree to use the new functions.
This will be done in the next commit.
Signed-off-by: Zygmunt Krynicki zygmunt.krynicki@canonical.com