On 8/10/20 3:59 PM, Jonas Große Sundrup wrote:
> Hi,
>
> I'm trying to restrict the access to /dev/shm. Some applications do
> require it, among these multiprocess-applications. I do suspect
> (although I have not yet explicitly tested it), that all processes
> might need to read and potentially write files there that have been
> created by another process of their tree. Hence, I'm thinking about how
> to best restrict access there as well and the natural though would be
> along the lines of apparmor-profiles, so the original binary and
> everything it spawns. Does apparmor have something in this regard?
>
unfortunately not yet, and it is questionable whether process hierarchy
would be involved in the rule.
There has been some discussion allowing process hierarchy as a control
for ptrace, ipc, and delegation. It might make sense here as well.
> The strictest option I currently see is
>
> owner /dev/shm/** rw
>
> but that would not have two processes under the same user but in
> different profiles still not separated.
>
Right
> Given that AppArmor revolves around filepaths, it feels to me like it
> might actually not be designed for this particular usecase, but as my
> experience with AppArmor is still limited maybe I'm lucky and there is
> something I haven't seen yet that allows even this kind of containment.
> This would certainly also be useful for things like /tmp if one were to
> nail down the processes in question.
>
So apparmor isn't exactly path based. Its a variant of DTE (domain type
enforcement). You see this in the ptrace, signal, dbus, rules which
expose the labeling on processes. We just haven't exposed it on files
yet.
WARNING, this is NOT available yet
shm files are going to have a labeling on them, by default set to the
label of the task that created them. And you will be able to do
owner label=@{self} /dev/shm/** rw,
it will also be able to manually set the label.
label:=special /dev/shm/** c,
Now this doesn't given process hierarchy but does limit it to tasks within
a given profile.
It is possible to add another conditional to make a restriction on profile
hierarchy if it is worthwhile to do so.
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
