If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite
It's quite sad that more blacklisting is being introduced. It would be much nicer to have InaccessibleDirectories=/ with whitelisting via ReadOnlyDirectories/ReadWriteDirectories in a working state... blacklists are a bad way to approach security.
It's quite sad that more blacklisting is being introduced. It would be much nicer to have InaccessibleDirectories=/ with whitelisting via ReadOnlyDirectories/ReadWriteDirectories in a working state... blacklists are a bad way to approach security.
This seems like it is unnecessarilly reinventing apparmor, poorly. Albeit, I guess directory access control is coming at it from another angle.
Apparmor already provides the necessary controls to restrict program behavior. I don't like how the usual default is no profile = go bananas, but you can fix that.
It has always been one of my largest gripes with Arch that MAC is not functional pretty much at all. If I knew anything about how to port apparmor profiles from Ubuntu or Suse where they have a huge stock of them (and I had the time) I'd try it. I think that is honestly the only thing holding me back from recommending Manjaro / Chakra to average users (not newbies yet, but the average joe should have good MAC support).
This seems like it is unnecessarilly reinventing apparmor, poorly. Albeit, I guess directory access control is coming at it from another angle.
Apparmor already provides the necessary controls to restrict program behavior. I don't like how the usual default is no profile = go bananas, but you can fix that.
It has always been one of my largest gripes with Arch that MAC is not functional pretty much at all. If I knew anything about how to port apparmor profiles from Ubuntu or Suse where they have a huge stock of them (and I had the time) I'd try it. I think that is honestly the only thing holding me back from recommending Manjaro / Chakra to average users (not newbies yet, but the average joe should have good MAC support).
Arch Linux has an official package for grsecurity, which has a great MAC implementation. The profiles are very easy to write, especially thanks to both full-system auto-learning and granular learning for specific subjects. It resolves the paths in the profile to inodes when the policy is loaded, so it doesn't have the security disadvantage associated with PATH-based MAC. It also has more power than the LSM alternatives since it's not limited to whatever hooks ended up all over the kernel for SELinux.
this is not an apparmor/selinux/tomoyo/grsecurity replacement, this is a previous step to those. This is a standard way across distro(using systemd ofc) to tell a service "hey i kinda don't trust you so you won't access my files generally speaking" to get early boot safe sandboxing, once the boot process kicks in your apparmor/selinux/tomoyo/grsecurity services take the fine grained control over what is accesible and how.
this is very useful in many scenarios:
1.) standarized basic sandbox: after all every distro use a different MAC implementation (fedora selinux, ubuntu apparmor, other tomoyo, arch grsecurity +, gentoo you choose, etc.)
2.) early boot service: some service start before your MAC, so for this period of time your files could be vulnerable
3.) embedded ARM/MIPS: nice for basic security without the extra weight of a full MAC system(especially in ARM low end hardware, they dont have extra cycles to waste in fine grained security)
Comment