Kernel parameters protecting fifos and regular files

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Kernel parameters protecting fifos and regular files

Craig Small-2
Hi,
  About 2 years ago the procps package added protection for hard and soft symlinks. The bug report was 889098 and has seemed to work fine.

There is also now bug #914859 which would extend this same protection for other files, as mentioned in [1]

On the one hand, having all these file types protected by default would be very nice. On the other, it may break things in odd ways though I suspect this is quite rare.  A system administrator is, of course, able to set these to whatever they would like, but what should the default be?

My personal preference is to lock them down by default, by setting both to mode 2. However the impact is way more than my handful of systems I use, hence the wider email.

Putting it another way, are there any real strong reasons for not doing this?
 - Craig




Reply | Threaded
Open this post in threaded view
|

Re: Kernel parameters protecting fifos and regular files

Richard Laager
On 1/28/20 9:23 PM, Craig Small wrote:
> My personal preference is to lock them down by default, by setting both
> to mode 2.
FWIW: I agree. Unless massive breakage is expected, the default should
be the most secure option. If you default to secure and that breaks
something, people will be motivated to fix it (either the root issue or
by changing the setting). If you default to compatible, very few people
will find the option and tweak it, so most people will lose out on the
security. If there is massive breakage, you can back it off, of course.

--
Richard


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Adding security features (was: Kernel parameters protecting fifos and regular files)

Marvin Renich
I have no opinion about this specific feature; at first glance it looks
like it might be a reasonable thing to do.  On the other hand, I
strongly disagree with this statement as a general rule:

> Unless massive breakage is expected, the default should
> be the most secure option.

This is the wrong way around.  In a general distribution, the default
should be to use the maximum amount of security that can reasonably be
expected to cause _minimal_ disruption to usability.  The above
statement implies that the default should be the maximum security that
does _not_ cause _maximum_ disruption.  (Even medium disruption is the
wrong balance for a general distribution's default.)

Time and time again I see security expert "wannabes" pushing for the
most security possible.  Even real experts sometimes lose sight of the
balance between usability and security.  Unfortunately, there are a lot
more "wannabes" than real experts, and the "wannabes" are typically much
more vocal.

If you change "Unless massive breakage is expected" to "If breakage is
expected to be minimal", than I would agree.

On the other hand, I do agree with using unstable and testing to
determine the level of disruption, on the condition that there is a
_commitment_ to removing the feature before stable release if the impact
on usability is more than minor.

I would like to give big kudos to the AppArmor team for providing Debian
developers and users with an exemplary experience while adding a
security feature as a distribution default.  I think the rollout went so
smoothly that the AppArmor team did not get enough attention for the
terrific job they did.  That transition should be held up as a model for
implementing any big feature change in Debian.

...Marvin

Reply | Threaded
Open this post in threaded view
|

Re: Kernel parameters protecting fifos and regular files

Moritz Muehlenhoff-5
In reply to this post by Craig Small-2
Craig Small <[hidden email]> schrieb:
> --0000000000004806c5059d3edeb1
> Content-Type: text/plain; charset="UTF-8"
>
> Hi,
>   About 2 years ago the procps package added protection for hard and soft
> symlinks. The bug report was 889098 and has seemed to work fine.
>
> There is also now bug #914859 which would extend this same protection for
> other files, as mentioned in [1]

I'm in favour of setting both to 1. From a quick search Ubuntu carried a patch
in their systemd package to set this as well (LP 1845637).

protected hardlinks/symlinks are enabled via a Debian-specific kernel patch
by default, so I'd say that src:linux should be patched as well, this changes
the default at the deepest level and the /etc/sysctl.conf kicks in for
anyone running custom built kernels.

Cheers,
        Moritz

Reply | Threaded
Open this post in threaded view
|

Re: Kernel parameters protecting fifos and regular files

Ben Hutchings-3
On Wed, 2020-01-29 at 10:13 -0800, Moritz Mühlenhoff wrote:

> Craig Small <[hidden email]> schrieb:
> > --0000000000004806c5059d3edeb1
> > Content-Type: text/plain; charset="UTF-8"
> >
> > Hi,
> >   About 2 years ago the procps package added protection for hard and soft
> > symlinks. The bug report was 889098 and has seemed to work fine.
> >
> > There is also now bug #914859 which would extend this same protection for
> > other files, as mentioned in [1]
>
> I'm in favour of setting both to 1. From a quick search Ubuntu carried a patch
> in their systemd package to set this as well (LP 1845637).
>
> protected hardlinks/symlinks are enabled via a Debian-specific kernel patch
> by default, so I'd say that src:linux should be patched as well, this changes
> the default at the deepest level and the /etc/sysctl.conf kicks in for
> anyone running custom built kernels.
There was discussion around this issue on #debian-kernel recently.
Changing the default in src:linux doesn't help people that get their
kernel from somewhere else.  Changing it in procps also doesn't cover
minimal installations since it's only Priority: important.

Is there a higher priority package, independent of init system, that
would be suitable for carrying the Debian sysctl policy?

Ben.

--
Ben Hutchings
I'm not a reverse psychological virus.
Please don't copy me into your signature.



signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Adding security features (was: Kernel parameters protecting fifos and regular files)

Richard Laager
In reply to this post by Marvin Renich
[ Note: I have reordered the quoted text blocks. ]

On 1/29/20 8:28 AM, Marvin Renich wrote:
> On the other hand, I do agree with using unstable and testing to
> determine the level of disruption, on the condition that there is a
> _commitment_ to removing the feature before stable release if the
> impact on usability is more than minor.

+1

I don't think we're that far apart here. There are plenty of shades of
grey in this, and what counts as "minimal", "medium", or "massive" is
going to be at least somewhat subjective.

> Even medium disruption is the
> wrong balance for a general distribution's default.

I'm willing to go a bit further than you, as I would take (again, my
subjective) "medium" disruption for a real security win, generally speaking.

> I would like to give big kudos to the AppArmor team for providing
> Debian developers and users with an exemplary experience while adding
> a security feature as a distribution default.

+1

AppArmor had the potential to cause massive breakage, and has not,
primarily due to it being opt-in. I think this has been a big success.

I would characterize AppArmor as being on the low end of "medium"
breakage. AppArmor is something that I need to care about on an on-going
basis as a sysadmin. I need to be aware it exists, how its problems will
manifest, how to debug it, and how to fix it. I can't completely ignore
it, as it does break things from time to time. This is not to say it
breaks things out-of-the-blue. It breaks things when I change
configurations away from the default. That's totally fine. I figure it
out and go add the appropriate bit to the local/tunable file.

Something minimally disruptive would be something like Address Space
Layout Randomization (ASLR). While that may have impacts on maintainers
enabling/disabling compiler flags, it is not something I ever have to
think about as a sysadmin. It is never the problem. I never need to do
anything related to it (as a sysadmin).

Something like SELinux in the RedHat world is probably still at least on
the high end of "medium" these days and could probably be characterized
as "massive breakage" in its early days. "Massive breakage" is the sort
of thing where large numbers of experienced sysadmins respond with "just
turn it off".

With what I know about this particular change right now, my assumption
is that it will cause little to no breakage. I would characterize the
expected impact as "minor". Further, I expect that any breakage will be
"one-time" breakage that can be addressed by application developers
and/or package maintainers, and it will not cause on-going work for
system administrators.

> > Unless massive breakage is expected, the default should
> > be the most secure option.

> The above
> statement implies that the default should be the maximum security that
> does _not_ cause _maximum_ disruption.

I'd say that "massive breakage" (breaking lots of things) is not the
same as "maximal disruption" (the most disruption). Maximum disruption
would be, for example, breaking things that were "fully correct" (not
doing something "dodgy") before the change. This would be a "flag day"
change. That level of disruption needs to be avoided if at all possible,
and carefully managed if completely unavoidable and worth the pain.

> Time and time again I see security expert "wannabes" pushing for the
> most security possible.  Even real experts sometimes lose sight of the
> balance between usability and security.  Unfortunately, there are a lot
> more "wannabes" than real experts, and the "wannabes" are typically much
> more vocal.

While I understand your point, I think it would be better to focus on
the arguments rather than the people making them.

--
Richard


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Adding security features (was: Kernel parameters protecting fifos and regular files)

Marvin Renich
* Richard Laager <[hidden email]> [200129 19:05]:
> On 1/29/20 8:28 AM, Marvin Renich wrote:
> There are plenty of shades of
> grey in this, and what counts as "minimal", "medium", or "massive" is
> going to be at least somewhat subjective.

Completely agree.

> I'd say that "massive breakage" (breaking lots of things) is not the
> same as "maximal disruption" (the most disruption). Maximum disruption
> would be, for example, breaking things that were "fully correct" (not
> doing something "dodgy") before the change. This would be a "flag day"
> change. That level of disruption needs to be avoided if at all possible,
> and carefully managed if completely unavoidable and worth the pain.

My intended meaning of disruption, in my previous message, was not the
inevitable churn associated with ironing out the bugs.  It was the
resulting decrease in ease of use (and increase of other costs) after
the bugs settled.  Sorry if that wasn't clear.

There is always a trade-off between security and usability.  My point is
to not force more security on everybody _as the default_ when only some
users need that security, and most of the time the users who need the
security are the ones who are able figure out the knob to tweak to get
it (and many times they are using something like puppet to ensure that
all the machines they support get the configuration they want).

Because of this, distributions, when choosing defaults, should give more
weight to the needs of those less likely to be able to do the
configuration themselves than to those with more advanced needs.  I do
agree that sometimes having a slightly higher level of security is the
best default; just give appropriate thought to the associated costs.

> > Time and time again I see security expert "wannabes" pushing for the
> > most security possible.  Even real experts sometimes lose sight of the
> > balance between usability and security.  Unfortunately, there are a lot
> > more "wannabes" than real experts, and the "wannabes" are typically much
> > more vocal.
>
> While I understand your point, I think it would be better to focus on
> the arguments rather than the people making them.

Okay, that paragraph was too pejorative.  Let me rephrase it.  (Note,
however, that I did not identify anyone in particular, nor did I have
any specific person or persons in mind.)

Some people actively and regularly encourage others (distributions,
large ISPs, etc.) to use a higher level of security as a default than
most people need without regard to how it affects usability and other
real costs (such as bandwidth and CPU usage, which affects how much
people have to spend).  Not only is setting the default level of
security too high a bad thing, but the act of promoting this is a bad
thing.  (This last sentence was really the point I was trying to make
with the paragraph in my previous message.)

If I offended anyone who considers themselves to be one of the people
described in the previous paragraph by calling them security expert
"wannabes" in my original message, I do apologize.  But please, stop
pushing for higher-than-necessary defaults for security.

As a specific example of unnecessary default security, take the "https
everywhere" campaign.  Having https available on most servers is
definitely good.  However, if you explicitly go to
http://www.google.com/ you are redirected to the https version.  Of all
the (hundreds of?) billions of google searches done every day, how many
of them would really cause any harm at all if the communications were
unencrypted?  Yet the entire computer-using segment of society pays the
price for higher bandwidth and CPU usage.

Note that my whole argument is not about what should or shouldn't be
available.  It is about what the defaults should be.

...Marvin

Reply | Threaded
Open this post in threaded view
|

Re: Adding security features

The Wanderer
On 2020-02-03 at 11:51, Marvin Renich wrote:

> As a specific example of unnecessary default security, take the
> "https everywhere" campaign.  Having https available on most servers
> is definitely good.  However, if you explicitly go to
> http://www.google.com/ you are redirected to the https version.  Of
> all the (hundreds of?) billions of google searches done every day,
> how many of them would really cause any harm at all if the
> communications were unencrypted?  Yet the entire computer-using
> segment of society pays the price for higher bandwidth and CPU
> usage.

I think part of the idea here is to promote a type of "herd immunity"
against surveillance. (That analogy may be a bad one.)

The more people do not use HTTPS for Google searches which aren't
sensitive enough to require security, the easier it is for surveillance
actors to distinguish the searches which do require it, and thereby
identify targets for subjecting to surveillance - or worse - by other
methods.

I understand that benefit - of making it easier for those who do need
the security to hide among the crowd - to be one of the major arguments
for having HTTPS be used everywhere and in all cases, even places and
cases which would not otherwise see any benefit from using it.

That argument does not necessarily generalize to other "higher security
by default" discussions, however, and at a glance I don't think I see
how it would apply to the one at hand in this thread.

--
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Adding security features

Anthony DeRobertis
In reply to this post by Marvin Renich
On 2/3/20 11:51 AM, Marvin Renich wrote:
>
> As a specific example of unnecessary default security, take the "https
> everywhere" campaign.  Having https available on most servers is
> definitely good.  However, if you explicitly go to
> http://www.google.com/ you are redirected to the https version.  Of all
> the (hundreds of?) billions of google searches done every day, how many
> of them would really cause any harm at all if the communications were
> unencrypted?

I think you've picked a really bad example, and I'm not sure if that's
because you grabbed something out of the air without really examining
it, but just in case it's not...

I think, first, you're asking the wrong question. Almost no one, and
definitely not the people we're setting the defaults for, would remember
to pick between http:// and https:// each time they're doing a search.
After all, we're presuming the default. So even if it turns out a small
percentage of searches, it can easily mean that it's a large percent of
*users*.

And it probably is. When I think of my own searches, sure, most are for
boring things like looking up an API. Or random computer
troubleshooting, or whatever. At first blush, even if those were public,
seems relatively harmless. But sometimes I search for e.g.,
medical/health things that I'd definitely be upset if they were public.
Of course, http doesn't mean public, but it definitely can — public WiFi
is everywhere, for example. That alone, I think, makes https-by-default
make sense for web searches.

But there is more. I've heard about plenty of research that it doesn't
actually take that many search queries to get a pretty good profile of a
person. All those queries that are innocuous taken individually when put
together get a lot more sensitive. I'd definitely rather not share that
info with my ISP, who of course could easily get it w/o https. (Choices
here are Verizon and Comcast, who do you trust less to not try this and
sell the results to the highest bidder?).

There is still more. Google results are heavily customized based on your
past searches, and include ads based on, well, everything Google knows
about you. Which (again, for the person defaults are targeted at) is a
lot. So even innocuous searches can wind up including private things in
the results. E.g., Google has at some point had results from Gmail in
the web search results (no idea if they currently do).

We've only considered eavesdropping so far. But Google is a high-profile
site, used by almost everyone, That makes it a very tempting target for
active attacks — everything from ISPs injecting their own ads and
content (not a hypothetical, even some large ISPs do this) to targeted
attacks (e.g., when a user gets a scary security warning about running
something from visiting Google.com, I bet "yes" is a much more likely
answer). And of course all the attacks essentially on Google; e.g.,
inject some JavaScript to fake clicks on ads on results pages. Etc.

Finally, the cost really isn't that high...

>   Yet the entire computer-using segment of society pays the
> price for higher bandwidth and CPU usage.

The funny thing about forcing the deployment of HTTPS everywhere is that
it got everyone on board with improving the protocols and
implementations. HTTP/2 (and eventually /3) and TLS/1.3 aren't really
that much slower than they would be w/o the encryption, modern ciphers
are plenty fast even on fairly low-end hardware, etc. We've even made
good progress on reducing the extra round-trips required (via session
resumption, multiplexing, and TLS False Start). On very slow links
(e.g., dial up modem), it's probably painful to lose link-layer
compression... but I can't imagine how dreadful the modern web must be
on dialup.

It's been a shame to lose web caches in some cases, too.

Reply | Threaded
Open this post in threaded view
|

Re: Adding security features

Nikolaus Rath
On Feb 04 2020, Anthony DeRobertis <[hidden email]> wrote:
> Google has at some point had results from
> Gmail in the web search results (no idea if they currently do).

Would you have a reference for this please?

Best,
-Nikolaus

--
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

Reply | Threaded
Open this post in threaded view
|

Re: Adding security features

Anthony DeRobertis


On February 5, 2020 9:49:36 AM UTC, Nikolaus Rath <[hidden email]> wrote:
>On Feb 04 2020, Anthony DeRobertis <[hidden email]> wrote:
>> Google has at some point had results from
>> Gmail in the web search results (no idea if they currently do).
>
>Would you have a reference for this please?

Here is a news report from when they were testing it:
 https://www.pcworld.com/article/260600/google_tries_showing_gmail_emails_in_search_results.html 

Not sure what came of it.

Reply | Threaded
Open this post in threaded view
|

Re: Adding security features

Nikolaus Rath
On Feb 05 2020, Anthony DeRobertis <[hidden email]> wrote:

> On February 5, 2020 9:49:36 AM UTC, Nikolaus Rath <[hidden email]> wrote:
>>On Feb 04 2020, Anthony DeRobertis <[hidden email]> wrote:
>>> Google has at some point had results from
>>> Gmail in the web search results (no idea if they currently do).
>>
>>Would you have a reference for this please?
>
> Here is a news report from when they were testing it:
>  https://www.pcworld.com/article/260600/google_tries_showing_gmail_emails_in_search_results.html 
>
> Not sure what came of it.

I think it's worth pointing out that this was an experimental feature
that users explicitly had to opt into. The original statement feels
misleading to me.

Best
-Nikolaus

--
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

Reply | Threaded
Open this post in threaded view
|

Re: Adding security features

Anthony DeRobertis
On 2/5/20 2:52 PM, Nikolaus Rath wrote:
>
> I think it's worth pointing out that this was an experimental feature
> that users explicitly had to opt into. The original statement feels
> misleading to me.


That's how it started, further looking (sorry, was replying from my
phone before) give things like
https://www.theandroidsoul.com/google-now-and-google-search-now-shows-your-recent-gmail-messages-when-you-search-my-inbox/ 
where various search terms show gmail messages. Which I just checked,
searching "my inbox" still works here. I don't think that's anything
special I've turned on, don't think "labs" even exists anymore in Gmail.

Reply | Threaded
Open this post in threaded view
|

Re: Kernel parameters protecting fifos and regular files

Craig Small-2
In reply to this post by Moritz Muehlenhoff-5


On Thu, 30 Jan 2020 at 05:26, Moritz Mühlenhoff <[hidden email]> wrote:
I'm in favour of setting both to 1. From a quick search Ubuntu carried a patch
in their systemd package to set this as well (LP 1845637).

protected hardlinks/symlinks are enabled via a Debian-specific kernel patch
by default, so I'd say that src:linux should be patched as well, this changes
the default at the deepest level and the /etc/sysctl.conf kicks in for
anyone running custom built kernels.
OK, I'll make them both 1 rather than 2 so there is some consistency.  I note the concern some have brought up about procps is not installed in some minimal installations but that's not the problem we're trying to solve here. They'll be in the next release.

Thanks all for the input.

 - Craig