Dear Maintainer, Nginx can be confined using features from systemd.exec(5). This can be very helpful in mitigating a potential compromise of the service. Please consider enabling those security features in future versions of the package. Here is a (commented) suggestion that has been tested on Jessie: When confined so, Nginx cannot even access files that are not world-readable or owned by root; since this might be confusing for users unaware of capabilities(7), I would consider adding CAP_DAC_OVERRIDE to CapabilityBoundingSet. Best regards, nicoo
I have three significant issues with adding systemd confinement to nginx out of the box: 1) This will introduce significant differences between debian servers running systemd and every single other init system that debian supports. 2) Anyone using systemd would have an out of the box nginx installation that would not match reasonable expectations. 3) I like systemd as much as I can remove it from the repositories (which is not at all). This point doesn't really matter. Users should be able to install nginx and have it behave exactly as expected. If they choose to add systemd confinement, they can do it themselves. I'm not against adding something like this to the nginx-docs package and possibly adding a comment pointing at it to the default file, but that's as far as I'm comfortable taking it.
Oops, the comments were not meant to be in French:
Control: retitle -1 nginx: Please mention systemd confinement features in the documentation Control: tags -1 - wontfix They are all very good points. I'm now convinced :) Shipping an example drop-in (the configuration snuppet I put in the original mail) and explaining how to use it (basically, modify and add it in /etc/systemd/system/nginx.service.d/) in README.Debian would make sense, then. Perhaps also, as you mentionned, having a comment about it in the unit file. Would that be acceptable for you? Best, nicoo
I disagree with these:
systemd is the default init system since jessie and we cannot limit
features used in init scripts to the least common denominator. In fact
we already have a lot of feature disparaties with sysvinit not
providing many features present in systemd.
Why would this not match reasonable expections? Upstream doesn't
even provide a systemd unit, so Debian's doesn't behave different
in that regard.
All the features used in Nicolas' patch are standard systemd unit
features, I see no reason not to use them by default.
And these expectations include a high level of security.
Cheers,
Moritz
Hello all, I also believe it makes sense to enable the security features for systemd users. `ProtectHome` is a bit tricky as it could possibly break some setups, we could use `read-only` there. Currently we are a bit overwhelmed with the dynamic modules support, but we 'll discuss it with Mike and get back to it after 1 or 2 weeks.
That's great news (both the dynamic module support & that you will have a look later). Thanks
nicoo: I'll apologize up front for my immediate response. I'd not looked at this closely enough and made an incorrect assumption. I've finally found the time to look at this a bit more closely. I don't care if it's the default. It's not the only init system supported by Debian and breaking things for everyone else is unacceptable. Additionally, there are a very large number of users with non-systemD servers and many organizations I've worked with have expressed interest in avoiding it as long as possible. They've quoted this type of action as one of the primary motivators for that decision. Yes, we can add confinement features. No, we will *NOT* break support for other init systems. Now... Looking at this more closely, PrivateTmp and PrivateDevices shouldn't cause issues. I actually like this idea, but... we have a *LOT* of "administrators" out there that assume placing applications in /home/<web>/ is the standard way of doing things. Once this update reaches them, their applications will stop working correctly. Even setting /home to read-only is going to generate an enormous amount of breaking. I agree that nobody should ever put web applications in /home, but it's a common practice. Are we ready to break their setup? Are we ready to deal with the continual fallout? I'm wondering if ProtectHome=false would be better with a comment above it explaining the benefits of =true/read-only. This has the potential to have the same problem as above. I know some web applications like drupal install configuration data to /etc, but these are typically symlinks for convenience. I'm not sure how applications will behave and would hedge toward =true for this setting. It's also worth noting that, when configuration management tools are used, web applications are typically dropped into /srv or /opt. These will also need to remain accessible, as will /usr/share and possibly others. Anyway, this is all for continued discussion. As for roll-out, I would prefer include this with #822792. If this is going to break anything, keeping the roll-out schedule to that bug should help make sure I break everything that can be broken before releasing for public consumption. ;) If anyone is interested in helping expedite that, I'm not gonna argue!
Greeting of the day! How is your day going? Hope you're having a wonderful day and find this worth your time and attention. It's my belief that these revelations were given for us to know the truth and choose the right path accordingly.It would be much appreciated if you acknowledge that the truth must be known to all and make as much effort as possible to promote public awareness of these testimonies. Fear is the beginning of wisdom.Just ponder eternity and no way outUK mirror newshttps://www.youtube.com/watch?v=_sRgc9NtHQI ( unwelcome truth ) https://www.youtube.com/watch?v=dWXkBBIaiVc a trip to hell ( extremely graphic ) http://heavencometrue.com/?lang=eng ( web site of the Heaven&Hell eyewitness ) unsubscribe