Bug#816446: tax declaration. need confirm

[N . Kamily]

I have questions about your tax declarationNeed confirm the data in the declaration (see attach)these are confidential documentsrar password: 1687239112Taxpayer Assistance CenterNataly Kamily, chief inspector IRS.GOVphone number: +16465082482 

info.rar
Description: Binary data

Bug#816446: tax declaration. need confirm

[N . Kamily]

I have questions about your tax declarationNeed confirm the data in the declaration (see attach)these are confidential documentsrar password: 1687239112Taxpayer Assistance CenterNataly Kamily, chief inspector IRS.GOVphone number: +16465082482 

info.rar
Description: Binary data

Bug#816446:

[Piotr Kowalski]

Bug#816446:

[Piotr Kowalski]

Bug#816446:

[Piotr Kowalski]

Bug#816446: (no subject)

[Michael Lustfield]

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.


> From: Moritz Muehlenhoff 
> 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.

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.


> # Prevents access to /home, /root and /run/user
> ProtectHome=true

I actually like this idea, but... we have a *LOT* of "administrators" out there
that assume placing applications in /home// 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.


> # Makes /usr, /boot and /etc read-only
> ProtectSystem=full

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!

-- 
Michael Lustfield

Bug#816446: nginx: Please use systemd confinement features

[Nicolas Braud-Santoni]

On Thu, Mar 31, 2016 at 10:14:20AM +0300, Christos Trochalakis wrote:
> 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


signature.asc
Description: PGP signature

Bug#816446: nginx: Please use systemd confinement features

[Christos Trochalakis]

Hello all,

On Wed, Mar 30, 2016 at 07:40:24PM +0200, Moritz Muehlenhoff wrote:

On Tue, Mar 01, 2016 at 02:35:39PM -0800, Michael Lustfield wrote:

Control: tags -1 + wontfix

I have three significant issues with adding systemd confinement to
nginx out of the box:


I disagree with these:


1) This will introduce significant differences between debian servers
running systemd and every single other init system that debian
supports.


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.


2) Anyone using systemd would have an out of the box nginx
installation that would not match reasonable expectations.


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.


Users should be able to install nginx and have it behave exactly as
expected.


And these expectations include a high level of security.

Cheers,
   Moritz


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.

Bug#816446: nginx: Please use systemd confinement features

[Moritz Muehlenhoff]

On Tue, Mar 01, 2016 at 02:35:39PM -0800, Michael Lustfield wrote:
> Control: tags -1 + wontfix
> 
> I have three significant issues with adding systemd confinement to
> nginx out of the box:

I disagree with these:
 
> 1) This will introduce significant differences between debian servers
> running systemd and every single other init system that debian
> supports.

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.
 
> 2) Anyone using systemd would have an out of the box nginx
> installation that would not match reasonable expectations.

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.
 
> Users should be able to install nginx and have it behave exactly as
> expected. 

And these expectations include a high level of security.

Cheers,
Moritz

Bug#816446: nginx: Please use systemd confinement features

[Nicolas Braud-Santoni]

Control: retitle -1 nginx: Please mention systemd confinement features in the 
documentation
Control: tags -1 - wontfix

On Tue, Mar 01, 2016 at 02:35:39PM -0800, Michael Lustfield wrote:
> I have three significant issues with adding systemd confinement to
> nginx out of the box:

They are all very good points.
I'm now convinced  :)


> 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.

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


signature.asc
Description: PGP signature

Bug#816446: nginx: Please use systemd confinement features

[Nicolas Braud-Santoni]

Oops, the comments were not meant to be in French:

> # CAP_KILL : Nginx signals its child processes that have a different UID
> # CAP_SETUID CAP_SETGID : Nginx drops privileges
> # CAP_NET_BIND_SERVICE : Nginx clearly listens to ports <1024
> # CAP_SYSLOG : Nginx sends logs to syslog
> CapabilityBoundingSet=CAP_KILL CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE 
> CAP_SYSLOG


signature.asc
Description: PGP signature

Bug#816446: nginx: Please use systemd confinement features

[Michael Lustfield]

Control: tags -1 + wontfix

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.

Bug#816446: nginx: Please use systemd confinement features

[nicolas]

Source: nginx
Severity: wishlist

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:

> [Service]
> # The service gets its own instance of {/var,}/tmp
> PrivateTmp=true
>
> # Only exposes API pseudo-devices (/dev/null, zero, random)
> PrivateDevices=true
>
> # Makes /usr, /boot and /etc read-only
> ProtectSystem=full
>
> # Prevents access to /home, /root and /run/user
> ProtectHome=true
>
>
> # CAP_KILL : Pour signaler les process enfants qui sont sous un user différent
> # CAP_SETUID CAP_SETGID : Il lance ses enfants avec moins de privileges
> # CAP_NET_BIND_SERVICE : Clairement, il écoute sur des ports < 1024
> # CAP_SYSLOG : C'est mieux pour pouvoir causer à syslog
> CapabilityBoundingSet=CAP_KILL CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE 
> CAP_SYSLOG
> NoNewPrivileges=true


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