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.
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.
Systemd devs, like all programmers, need bug reports, not personal attacks and hate headlines, when something breaks. If all those attacks on systemd force systemd devs to turtle up and try everything new in private for fear of being attacked over bugs in alpha code, you get more bugs instead of less bugs when code gets released into system configurations the programmers don't have on hand for testing.
Expect alpha code to have issues, expect finished code used in released versions of operating systems to be reliable. These go together folks! Let's face it, a lot of people are using systemd right now, and they need code that works. Many of us appreciate core security upgrades that can be used to say, sandbox the network and block remote attacks.
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.
BTW, I'm still wondering if there is any security researcher auditing systemd...
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).
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 )
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.
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.