What kind of policies would you accept? As I said, I really want to see Arch usable for everyone I know and not just myself, but they need good MAC that I can trust with a comprehensive included policy set. I just don't see the likelihood of out of tree patches being added to the Arch stock kernel, so I don't even see the road that leads to getting it into the stock kernel. And if it isn't in the stock one, there are all the aur or extended kernel mods like ck or pf that won't build it, and you end up compiling your own kernels if you want the latter stuff. Albeit, having used the ck and pf patchsets, I always end up going back to stock just because the maintenance and circumstantial breakage gets excessive. And my last point of contention is that grsecurity is not used in any major mainstream distribution,
Originally Posted by strcat
I'll try it the grsecurity Arch kernel this weekend, though. Is there an IRC / mailing list for its development? I do want to get involved at some point with policy creation, albeit I'm coming from a guy who has only contributed to Suse apparmor profiles and has never used the gr tools. I'll need to get some reading done...
Some initial impressions though, after reading the wiki pages, READMEs from the grsec site, and a new superuser posts about it:
1. They don't try to mainline it because they don't want parts in the mainline kernel, they want the whole package - and they perceive the kernel developers as security hostile. Honestly, my biggest issue with this project is that it looks like it can never become mainline, and thus it can never become popular. This is why I've always supported apparmor - it is flawed, it is insufficient, it breaks a lot, but it is better than nothing and usable. I have no gripes with it if the majority of the Arch ecosystem considers adopting it, though.
2. Is there a way to only use per subject policies, rather than user policies? For single user systems polkit and systemd already do the appropriate resource allocations to unprivileged users, the user profiles seem redundant in that context - usually the DAC policies of the packages themselves are more than sufficient, and what I really want is binary hardening and restricted policies so exploited network facing software can't start jacking the entire system. I get where they have value on, say, a huge LDAP server, where just having custom groups for each user class is insufficient.
3. I thought the stock kernel already does ASLR and has noexec page flags.
The profiles look very apparmor-esque, though, which is good. Trying to do any access control in SELinux makes me want to devour brains since mine melted. Network access controls are nice and fine grained...
Damn it, the more I'm reading about gr, I'm strongly regretting my writing it off years ago under the pretense "it is not mainline, it can never be serious". Kind of hypocritical to think the LSM model is a broken wreck and ridiculous while not considering out of tree security models that avoid using it.
Also, this is making me really want to think about switching my server to Arch from Debian just for the gr kernel.
Last edited by zanny; 06-04-2014 at 06:54 PM.
Probably going to go through the front door in fedora 22.
I don't like systemd - but that's no reason to be incorrect on purpose and I see a lot of misinformed FUD here
Check the actual commit. http://cgit.freedesktop.org/systemd/...a7800846482eed
These are namespace mount flags - you can emulate that with unshare (man 1 unshare).
This is much simpler and faster than setting up RBAC through any mechanism. Its basically a different view of the filesystem mount. Fast/simple.
Note that grsec gets a lot of positive advertisement as being the underdog/not in mainline and theres a lot of great stuff with it, but in the real world it isnt all that much better or worse than other alternatives. LSM for example isnt limited at all. Its less safe against kernel compromise. But for most people, if the kernel is compromised in any way, its already game over. And in most cases, for GrSec RBAC it is.
The real gem in the GrSec kernel is that it includes PaX. At the same time PaX code is tracked by extremely large patch files with no history, making it difficult to understand and audit. And thats why its not in mainline.
Yes, in an ideal world where everyone was acting objectively and logically that would be the case. In the real world, however, there is a lot of irrational hatred of systemd, and there are "news" outlets that are willing to pounce on the smallest issue and spin it into a massive failure. There is a large social component to free software, and ignoring the implications of that is not a good way to encourage usage, and by extension contributions, to your project.
Originally Posted by Luke
I am pretty sure systemd went through a security audit prior to inclusion in Red Hat. There were some minor issues, but all fixable.
Originally Posted by asdfblah
On the other hand, what sort of security audit do distro init scripts get?
The Red Hat Security Response Team (security audit) is quite active, and they did have a look at systemd (they have filled several CVE for systemd in the past).
Originally Posted by asdfblah
You can be sure that the version that will end up in RHEL 7 will be fully audited.
They can also access to file that are world readable. ( not that it change much, but that's for nitpicking )
Originally Posted by rmiller
Which is possible. When I was using Owncloud 2.X I kept all of my files in my home directory instead of /srv/www/Owncloud/Data/ just for easier backup. In order of Apache/Nginx to read and write to the folders I had to mess with the permissions-- which eventually just descended into me making them 777 because for some reason even with "proper" group and user listing Owncloud wouldn't work right with them.
Originally Posted by misc
The example's not perfect, but the point I was trying to make is: None of us have any idea of what crazy, hackish setups people either choose to use / get forced to use to make something work.. So we have to work with that unknown.