4 ms·

> I could not find any example of what is impossible in AppArmor, AppArmor is simply less granular. For example, it doesn't provide true RBAC or MLS security m

> I could not find any example of what is impossible in AppArmor, AppArmor is simply less granular. For example, it doesn't provide true RBAC or MLS security models. It also uses paths instead of inodes, so a hard link can be used to override some policies. So it just depends on what the exploit or attack is trying to do. If an attacker gets root and is trying to overwrite a file, they may be able to. Maybe they can't, but they could probably still execute any code they can write and compile themselves. And perhaps they can write to other files and do damage. SELinux and similar systems allow a lot more granularity. Programs and users can only talk to explicit what they are allowed to talk to, and maybe you want to limit the access to say, append instead of full write access. It just allows a lot more granularity and restriction, that's the difference.

NewJazz 2y ago
> It also uses paths instead of inodes, so a hard link can be used to override some policies The link rules can get pretty granular and seem explicitly designed to prevent that scenario. https://man.archlinux.org/man/extra/apparmor/apparmor.d.5.en#Link_rules https://man.archlinux.org/man/extra/apparmor/apparmor.d.5.en... > they could probably still execute any code they can write and compile themselves Assuming the AppArmor profile allows writing to and executing the same files. Which isn't particularly common. > maybe you want to limit the access to say, append instead of full write access This is possible with AppArmor.
- ruthmarx 2y ago
  > The link rules can get pretty granular and seem explicitly designed to prevent that scenario. It's still an inherent weakness. No getting around that really. > Assuming the AppArmor profile allows writing to and executing the same files. Which isn't particularly common. I don't really want to try and come up with examples just so you can show there might be some hacky way of accomplishing something similar to what SELinux can offer - it would be missing my point. Point is there's a lot more you can do under AppArmor than SELinux. AppArmor isn't as granular and you can't lock down a system to the same extent, period. Is it good enough, sure. Is it better than nothing? Absolutely. Is it comparable to an optimized SELinux config? Not remotely. > This is possible with AppArmor. See above.
  - NewJazz 2y ago
    Hacky way to accomplish something? Literally every example you gave of AA not being "granular" enough was flat misinformation. There are dedicated rules to prevent writing and executing the same file, prevent using hardlinks to gain privileges, and prevent overwriting a file that should be append only. No hacks here. Just facts.
    - ruthmarx 2y ago
      > Hacky way to accomplish something? Yes. > Literally every example you gave of AA not being "granular" enough was flat misinformation. No, there was no misinformation, and this stance you're committed to defending is one of the most bizarre stances I've ever come across. There can be no question that SELinux is significantly more granular than AppArmor any more than there is that the earth is not flat. Looking at the introductory documentation for both systems should be more than enough to make that abundantly clear to anyone. > There are dedicated rules to prevent writing and executing the same file, prevent using hardlinks to gain privileges, and prevent overwriting a file that should be append only. No hacks here. Just facts. So just before I put more effort into replying to you, I want to be 100% clear on your stance. If I am paraphrasing or misconstruing, please correct. It seems like you are claiming that AppArmor using hardlinks is not any sort of vulnerability or weakness and cannot be, and has never been bypassed? Is this a fair reading of your position?
      - NewJazz 2y ago
        My position is that you haven't demonstrated a practical example of SELinux being able to constrain a workload that AppArmor doesn't have parity with, i.e. you haven't responded to my initial question: Can you offer some examples of things you can restrict with SELinux that you wouldn't be able to with AppArmor? Only valid answer in the thread has been port bindings - AppArmor's network rules don't allow restricting port number, but SELinux can do that. You tried to claim that SELinux could prevent processes from overwriting files instead of just appending to them while AppArmor could not do the same, but that statement of yours was easily disprovable -- the man page of apparmor.d shows that append-only rules are supported. If you don't want me to call your statement misinformation, then maybe invent another word because that is the only word I have to describe what you said.

NewJazz 2y ago

> It also uses paths instead of inodes, so a hard link can be used to override some policies The link rules can get pretty granular and seem explicitly designed to prevent that scenario. https://man.archlinux.org/man/extra/apparmor/apparmor.d.5.en#Link_rules https://man.archlinux.org/man/extra/apparmor/apparmor.d.5.en... > they could probably still execute any code they can write and compile themselves Assuming the AppArmor profile allows writing to and executing the same files. Which isn't particularly common. > maybe you want to limit the access to say, append instead of full write access This is possible with AppArmor.

ruthmarx 2y ago
> The link rules can get pretty granular and seem explicitly designed to prevent that scenario. It's still an inherent weakness. No getting around that really. > Assuming the AppArmor profile allows writing to and executing the same files. Which isn't particularly common. I don't really want to try and come up with examples just so you can show there might be some hacky way of accomplishing something similar to what SELinux can offer - it would be missing my point. Point is there's a lot more you can do under AppArmor than SELinux. AppArmor isn't as granular and you can't lock down a system to the same extent, period. Is it good enough, sure. Is it better than nothing? Absolutely. Is it comparable to an optimized SELinux config? Not remotely. > This is possible with AppArmor. See above.
- NewJazz 2y ago
  Hacky way to accomplish something? Literally every example you gave of AA not being "granular" enough was flat misinformation. There are dedicated rules to prevent writing and executing the same file, prevent using hardlinks to gain privileges, and prevent overwriting a file that should be append only. No hacks here. Just facts.
  - ruthmarx 2y ago
    > Hacky way to accomplish something? Yes. > Literally every example you gave of AA not being "granular" enough was flat misinformation. No, there was no misinformation, and this stance you're committed to defending is one of the most bizarre stances I've ever come across. There can be no question that SELinux is significantly more granular than AppArmor any more than there is that the earth is not flat. Looking at the introductory documentation for both systems should be more than enough to make that abundantly clear to anyone. > There are dedicated rules to prevent writing and executing the same file, prevent using hardlinks to gain privileges, and prevent overwriting a file that should be append only. No hacks here. Just facts. So just before I put more effort into replying to you, I want to be 100% clear on your stance. If I am paraphrasing or misconstruing, please correct. It seems like you are claiming that AppArmor using hardlinks is not any sort of vulnerability or weakness and cannot be, and has never been bypassed? Is this a fair reading of your position?
    - NewJazz 2y ago
      My position is that you haven't demonstrated a practical example of SELinux being able to constrain a workload that AppArmor doesn't have parity with, i.e. you haven't responded to my initial question: Can you offer some examples of things you can restrict with SELinux that you wouldn't be able to with AppArmor? Only valid answer in the thread has been port bindings - AppArmor's network rules don't allow restricting port number, but SELinux can do that. You tried to claim that SELinux could prevent processes from overwriting files instead of just appending to them while AppArmor could not do the same, but that statement of yours was easily disprovable -- the man page of apparmor.d shows that append-only rules are supported. If you don't want me to call your statement misinformation, then maybe invent another word because that is the only word I have to describe what you said.