Re: [apparmor] deny and selectively allow in AppArmor?
On 8/7/20 1:12 PM, Christian Boltz wrote:
> Hello,
>
> Am Freitag, 7. August 2020, 19:07:41 CEST schrieb Jonas Große Sundrup:
>> I have one question left, when we're at it: If I do have conflicting
>> directives, such as
>>
>> /my/directory r,
>> /my/directory rw,
>>
>> which one takes precedence? the first, the last, the stricter or the
>> broader?
>
> They get added up - so in your example, you'll get rw.
>
> As another example,
>
> /foo rwl,
> /foo wk,
>
> will effectively give you /foo rwlk,
>
>> In case of nested I'd suspect that AppArmor will just nest the
>> policies accordingly, no matter in which order they occur, right?
>
> The rule order doesn't matter.
>
>
Let me expand on this a bit. AppArmor syntax is declarative so rule order
doesn't matter as Christian has said.
However its a little more complicated than they just added up.
1. They only add up where the rules overlap
/** rk,
/foo w,
will give /foo rwk, permissions, but the rest of the files that only match /**
will only have rk permissions
2. deny has priority. You can think of it as add up all the allow rules in one
set and all the deny in another and subtract the deny set from the allow set.
3. Exec rule qualifiers use a most specific match priority.
ix /**,
px /foo/bar,
the px rule is more specific, so px will be used for /foo/bar, while ix would
be used for everything else
3.1. Exec rule dominance is not fully implemented yet. So it only works with
exact match rules like in the above example.
ix /usr/**,
px /usr/bin/*,
currently will report a conflict because the /usr/bin/ being more specific is
not correctly resolved.
4. The most specific match applies to profile attachments, with a fallback to
longest left specific match for policy not sharing an attachment dfa.
profile usr /usr/** { }
profile bin /usr/bin/* { }
basically, this means the above will work as expected. But the conflict is
found in the kernel at runtime instead of during compile. The kernel can handle
overlapping rules to a point (its not perfect) and will fail the exec if its
heuristics can resolve the dominance. Also newer kernels are better at this
than older kernels.
5. There will be language extensions at some point allowing a form of rule
priority, but that is not available yet.
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
Re: [apparmor] [PATCH] security: apparmor: delete repeated words in comments
On Fri, Aug 07, 2020 at 09:50:55AM -0700, Randy Dunlap wrote:
> Drop repeated words in comments.
> {a, then, to}
>
> Signed-off-by: Randy Dunlap
> Cc: John Johansen
> Cc: apparmor@lists.ubuntu.com
> Cc: James Morris
> Cc: "Serge E. Hallyn"
> Cc: linux-security-mod...@vger.kernel.org
Reviewed-By: Seth Arnold
Thanks
> ---
> security/apparmor/include/file.h |2 +-
> security/apparmor/path.c |2 +-
> security/apparmor/policy_unpack.c |2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> --- linux-next-20200731.orig/security/apparmor/include/file.h
> +++ linux-next-20200731/security/apparmor/include/file.h
> @@ -167,7 +167,7 @@ int aa_audit_file(struct aa_profile *pro
> * @perms: permission table indexed by the matched state accept entry of @dfa
> * @trans: transition table for indexed by named x transitions
> *
> - * File permission are determined by matching a path against @dfa and then
> + * File permission are determined by matching a path against @dfa and
> * then using the value of the accept entry for the matching state as
> * an index into @perms. If a named exec transition is required it is
> * looked up in the transition table.
> --- linux-next-20200731.orig/security/apparmor/path.c
> +++ linux-next-20200731/security/apparmor/path.c
> @@ -83,7 +83,7 @@ static int disconnect(const struct path
> *
> * Returns: %0 else error code if path lookup fails
> * When no error the path name is returned in @name which points to
> - * to a position in @buf
> + * a position in @buf
> */
> static int d_namespace_path(const struct path *path, char *buf, char **name,
> int flags, const char *disconnected)
> --- linux-next-20200731.orig/security/apparmor/policy_unpack.c
> +++ linux-next-20200731/security/apparmor/policy_unpack.c
> @@ -39,7 +39,7 @@
>
> /*
> * The AppArmor interface treats data as a type byte followed by the
> - * actual data. The interface has the notion of a a named entry
> + * actual data. The interface has the notion of a named entry
> * which has a name (AA_NAME typecode followed by name string) followed by
> * the entries typecode and data. Named types allow for optional
> * elements and extensions to be added and tested for without breaking
>
> --
> AppArmor mailing list
> AppArmor@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/apparmor
signature.asc
Description: PGP signature
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
Re: [apparmor] deny and selectively allow in AppArmor?
Hello,
Am Freitag, 7. August 2020, 19:07:41 CEST schrieb Jonas Große Sundrup:
> I have one question left, when we're at it: If I do have conflicting
> directives, such as
>
> /my/directory r,
> /my/directory rw,
>
> which one takes precedence? the first, the last, the stricter or the
> broader?
They get added up - so in your example, you'll get rw.
As another example,
/foo rwl,
/foo wk,
will effectively give you /foo rwlk,
> In case of nested I'd suspect that AppArmor will just nest the
> policies accordingly, no matter in which order they occur, right?
The rule order doesn't matter.
> On 2020-08-06, Christian Boltz wrote:
> > You could do some trickery with regexes. Annoying, but still better
> > than having to deny each and every file separately. Something like
> >
> >this:
> > deny owner @{HOME}/, # deny directory listing of the home directory
> > deny owner @{HOME}/[^.]**,
> > deny owner @{HOME}/[^.][^m]**,
> > deny owner @{HOME}/[^.][^m][^o]**,
> > deny owner @{HOME}/[^.][^m][^o][^z]**,
Looking at this again, I noticed a bug - it needs to be
deny owner @{HOME}/[^.]**,
deny owner @{HOME}/.[^m]**,
deny owner @{HOME}/.m[^o]**,
deny owner @{HOME}/.mo[^z]**,
> I thank you kindly for the proposal, but I think I'll avoid this
> approach. ;)
Good decision ;-)
Regards,
Christian Boltz
--
[after 4 bugreports] that should be all of them
well, at least until there's an openSUSE kernel with stacking
available ;-)
cboltz: no, no, no, see this is why we can't upstream,
cboltz will break everything
[from #apparmor]
signature.asc
Description: This is a digitally signed message part.
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
Re: [apparmor] deny and selectively allow in AppArmor?
Hi,
On 2020-08-06, John Johansen wrote:
> apparmor is default deny
I wasn't aware of that part, probably didn't read that part of the
documentation well enough to remember in that moment and during my
testing this likely didn't work because down the tree of included
abstractions
On 2020-08-06, Christian Boltz wrote:
> do you have any rule in your profile that _allows_ access to the home
> directory?
this was the case. default-deny does make a lot more sense with regards
to a MAC-system indeed.
I took an evening cleaning out the abstractions to suit my needs and
now things do indeed work like I want them to! And most of the
abstractions are now hand-curated, so I actually know what each of them
does.
Thank you very much for the pointers!
I have one question left, when we're at it: If I do have conflicting
directives, such as
/my/directory r,
/my/directory rw,
which one takes precedence? the first, the last, the stricter or the
broader?
In case of nested I'd suspect that AppArmor will just nest the policies
accordingly, no matter in which order they occur, right?
~ Jonas
On 2020-08-06, Christian Boltz wrote:
> You could do some trickery with regexes. Annoying, but still better
> than having to deny each and every file separately. Something like
>this:
>
> deny owner @{HOME}/, # deny directory listing of the home directory
> deny owner @{HOME}/[^.]**,
> deny owner @{HOME}/[^.][^m]**,
> deny owner @{HOME}/[^.][^m][^o]**,
> deny owner @{HOME}/[^.][^m][^o][^z]**,
> deny owner @{HOME}/[^.][^m][^o][^z][^i]**,
> deny owner @{HOME}/[^.][^m][^o][^z][^i][^l]**,
> deny owner @{HOME}/[^.][^m][^o][^z][^i][^l][^l]**,
> deny owner @{HOME}/[^.][^m][^o][^z][^i][^l][^l][^a]**,
I thank you kindly for the proposal, but I think I'll avoid this
approach. ;)
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
[apparmor] [PATCH] security: apparmor: delete repeated words in comments
Drop repeated words in comments.
{a, then, to}
Signed-off-by: Randy Dunlap
Cc: John Johansen
Cc: apparmor@lists.ubuntu.com
Cc: James Morris
Cc: "Serge E. Hallyn"
Cc: linux-security-mod...@vger.kernel.org
---
security/apparmor/include/file.h |2 +-
security/apparmor/path.c |2 +-
security/apparmor/policy_unpack.c |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
--- linux-next-20200731.orig/security/apparmor/include/file.h
+++ linux-next-20200731/security/apparmor/include/file.h
@@ -167,7 +167,7 @@ int aa_audit_file(struct aa_profile *pro
* @perms: permission table indexed by the matched state accept entry of @dfa
* @trans: transition table for indexed by named x transitions
*
- * File permission are determined by matching a path against @dfa and then
+ * File permission are determined by matching a path against @dfa and
* then using the value of the accept entry for the matching state as
* an index into @perms. If a named exec transition is required it is
* looked up in the transition table.
--- linux-next-20200731.orig/security/apparmor/path.c
+++ linux-next-20200731/security/apparmor/path.c
@@ -83,7 +83,7 @@ static int disconnect(const struct path
*
* Returns: %0 else error code if path lookup fails
* When no error the path name is returned in @name which points to
- * to a position in @buf
+ * a position in @buf
*/
static int d_namespace_path(const struct path *path, char *buf, char **name,
int flags, const char *disconnected)
--- linux-next-20200731.orig/security/apparmor/policy_unpack.c
+++ linux-next-20200731/security/apparmor/policy_unpack.c
@@ -39,7 +39,7 @@
/*
* The AppArmor interface treats data as a type byte followed by the
- * actual data. The interface has the notion of a a named entry
+ * actual data. The interface has the notion of a named entry
* which has a name (AA_NAME typecode followed by name string) followed by
* the entries typecode and data. Named types allow for optional
* elements and extensions to be added and tested for without breaking
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
