[apparmor] any way of denying profiled executable(s) to be ran at all

[janko metelko]

Thank you John for your very extensive and clear answer and explanation! I
had to read it twice to really get it, but now I see :). I find AppArmor
really interesting and also simple to use.

I will continue to explore AppArmor as I intend to use it on my servers and
my work computer. I find it funny that this technology seems so helpful and
I or my colleagues weren't even really aware of it.
I will also try to integrate it into a programming language I am working on
(ryelang.blogspot.com) as I think all serious apps of the future will have
to be well integrated with something like apparmor.
(I intend to make Rye so that it can also only evaluate source files signed
with specific ed25519 keys, but I have to make the Rye binary irreplaceable
then, it seems AA could also help me with that)

Thanks again!
Janko

On Wed, Nov 16, 2022 at 9:31 PM John Johansen <john.johansen at canonical.com>
wrote:

> On 11/16/22 11:59, janko metelko wrote:
> > Thank you for making AppArmor, if any of the developers are here. I am
> not a security guy, but such a solution seems like it should or will become
> an absolute must-use for any application deployment, locally or on a server.
> >
> > I have a question. I want to make a profile that prevents execution of
> any file from user-writable directories like /home /tmp, *except* if the
> executable has a AA profile.
> >
> > This would effectively mean that the user (or user level process) can't
> (knowingly or unknowingly) "install" and run anything that wasn't
> "confirmed" by root.
> >
> > It seems I can do this by creating an empty profile for /home/** which
> denies everything and then creating separate AA profiles for specific
> executable files inside /home that I allow to run.
> >
> > If I understand it right, all executables in /home without profiles will
> in this case crash or at least can't do any side effects since they are
> blocked from all IO/shared libs/configs/etc. In practice, they will
> probably just crash. It would be much nicer experience if such apps would
> be prevented to run, not start and crash.
> >
> > But I can only find directives in AA, that limit or allow certain
> resorces to the executable, and no directive, that would prevent executable
> to be ran in the first place.
> >
> > Is there any such solution? Am I maybe looking at it all wrong? Should I
> do this on another level, not with AppArmor?
> >
> > *Example*
> >
> > Maybe stupid example, but still. Let's say I want to prevent non-root
> users or RCEs from wget-ing into any other directory other than /tmp. I can
> simply create a profile for /usr/bin/wget { ... /tmp w, } and the job is
> done. But user/RCE can then simply do cp /usr/bin/wget ~/mywget and use
> wget for whatever it wants. If we prevent execution of non-profiled
> executables in user writable directories then he/it can't do that and our
> primary objective stands.
> >
> > I hope it makes some sense ... Thank you again. Ubuntu rocks also, and
> Xubuntu! :)
> >
>
> So lets split this into two cases.
> 1. Executing an application when confined
> 2. Executing an application when unconfined
>
> there are some differences so it is worth covering
>
> 1. Executing an application when confined
>
> When an application is confined all execs are covered by the profiles
> domain transition rules. Those rules require a qualifier to determine what
> should be done at exec.
> ix - inherit
> px - transition to a profile if it exists, otherwise FAIL the exec
> cx - transition to a child profile if it exists, otherwise FAIL the exec
> ux - transition to unconfined
>
> there are currently a set of fallback options available instead of failing
> the exec
> pix, cix - transition to profile if it exists, otherwise inherit current
> confinement
> pux, cux - transition to profile if it exists, otherwise transition to
> unconfined.
>
> you can also explicitly deny an exec with a deny rule
>
>    deny x /tmp/*,  # no need for a qualifier on deny rules
>
>
> So in this case there are a few ways to deny at exec time instead of
> crashing
>
>
> 2. Executing an application when unconfined
>
> This case is the currently problematic one. Where unconfined tasks
> essentially use an exec rule of
>
>    pix /**,
>
> meaning no exec will fail, it will either transition to a defined profile
> or allow the exec to continue as unconfined.
>
> Currently the only way to deal with this is indeed create a "trap" profile
> that doesn't grant permissions, causing the application to fault after exec
>
> profile trap /tmp/** {
>    # no permissions.
> }
>
>
> Obviously this is less than satisfactory. Ideally to avoid this you would
> be in situation #1, but the reality is that this just isn't how apparmor
> has been deployed and not all user tasks are confined.
>
>
> There is work going on to fix this, but it has not landed as of upstream
> kernel 6.1 or Ubuntu 22.10. When it lands (hopefully 23.04) you will be
> able to specify attachments that should be denied. Instead of having to
> create a trap profile. It will be a rule similar to what is in the profile.
>
>    deny x /tmp/**,
>
> and will have the longest left match prioritization, that attachments
> currently have. That is
>
>    deny x /**,
>
> would stop execution of anything that didn't have a profile defined. But
> since
>    profile example /bin/foo { }
>
> has a more specific attachment match it would take priority and allow exec
> under that profile.
>
>

-- 

Janko Metelko

Refaktor Labs, InvoiceFox, Cebelca.biz, UsrJoy ..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20221117/a18fed40/attachment.html>