Dr. Nikolaus Klepp <office@???> wrote:

>> I doubt this could be ever implemented correctly as you have to check
>> every code path of every app you will armorize or as soon as your usage
>> diverges from what the distro gurus have envisioned your program
>> will stop working without even a warning.
>> Next then we will need a uber-apparmor that checks apparmor safety
>> and anyway more code more bugs less security. Why not fix the existing
>> programs instead?
>
> The point is to delegate access control to a higher instance e.g. kernel. The problem is, that apparmor looks at a program from the the outside and tries to do the right thing with that black box - or what the profiles provider thought was the right thing.
>
> OpenBSD has quite an interesting aproach with unveil ( https://man.openbsd.org/unveil.2 ) and pledge ( https://man.openbsd.org/pledge ). The programmer itself takes care what the program will use and tells the system that what e.g. access privileges it does not want to use from now on. That's the look at the world from the inside, no black box involved. If you droped things, you can never get them back, so evil hackers code is confined inside the same cage.

As I see it, both approaches have merit.
The downside of doing it inside the application is that you are then trusting the programmer to have got the protection code correct - when we are assuming the function of the protection code is to protect from the programmer's errors. Yes, dropping privileges is a good idea - as long as it's done reliably.
The alternative of looking from the outside at a black box is that the person doing the looking was not the one building the black box. Thus while you lose the granularity possible when doing it from inside the box, you have created a separation of functions.

I don't think either approach is "right" or "wrong" - but doing both would probably be best.

Simon