Looking at https://unix.stackexchange.com/questions/135115/apparmor-pro... wouldn't raw sockets still be allowed under your blacklist policy? What about bluetooth and other radio interfaces? If an AppArmor evangelist can let so much through accidentally then that's a red flag. The thing that confuses me the most about AppArmor is it appears to be part of Linux, but I have no idea where its API exists. For example, there's nothing in the system calls table that says AppArmor. I tried running `aa-exec ls` under strace and I don't see any system calls that appear to be doing sandboxing. I tried putting your suggested config in an ls.apparmor file and passing that along as `aa-exec -p ls.apparmor ls` but it didn't work, since I think it requires you put profiles in /etc as root. That kind of defeats the whole point of us wanting a non-root sandboxing tool.
I am just its (mostly happy) user. I wrote that rule on my phone so you are right, it is not complete. On the other hand raw sockets require CAP_NET_RAW capability which is often assigned to root only so running a capability-untreated binary as an unprivileged user should not allow any raw socket ops (ping often uses file capabilities or setuid root).
AFAIK it requires root to load/reload profiles. And that is fine for me, my use-case is hardening of services running on my server.
But I agree that software developers know their software the best so they should be the ones writing the rules and ideally configure them depending on automake/configure paths (i.e. different PREFIX, this software/profile separation is annoying) but pledge() looks too old and non-flexible for such a job IMO. Most software need file ops but don't need to write everywhere.
I'm sure it's great but it requires setuid privileges. If it needs root it isn't ad-hoc.
> But I agree that software developers know their software the best so they should be the ones writing the rules
Exactly! You get it. pledge() is basically an App Store permissions model in spirit. It's curated and, like Android / Apple devs, the developer is thinking about what permissions they'll need to ask for at each step of writing their program. Not needing root is an important aspect of enabling that. The good news is that with SECCOMP BPF and Landlock I think we finally have a comprehensive solution for building the perfect unprivileged sandbox.
