Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1652725 > unrolled thread
| Started by | Matt Brown <matt@nmatt.com> |
|---|---|
| First post | 2017-05-29 23:40 +0200 |
| Last post | 2017-05-30 02:20 +0200 |
| Articles | 7 on this page of 47 — 11 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
[PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN Matt Brown <matt@nmatt.com> - 2017-05-29 23:40 +0200
Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN Alan Cox <gnomes@lxorguk.ukuu.org.uk> - 2017-05-30 00:30 +0200
Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN Boris Lukashev <blukashev@sempervictus.com> - 2017-05-30 02:00 +0200
Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN Casey Schaufler <casey@schaufler-ca.com> - 2017-05-30 02:30 +0200
Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN Matt Brown <matt@nmatt.com> - 2017-05-30 04:10 +0200
Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN Casey Schaufler <casey@schaufler-ca.com> - 2017-05-30 04:50 +0200
Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN Matt Brown <matt@nmatt.com> - 2017-05-30 05:20 +0200
Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN Alan Cox <gnomes@lxorguk.ukuu.org.uk> - 2017-05-30 14:30 +0200
Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN Matt Brown <matt@nmatt.com> - 2017-05-30 18:30 +0200
Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN Daniel Micay <danielmicay@gmail.com> - 2017-05-30 18:50 +0200
Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN Stephen Smalley <sds@tycho.nsa.gov> - 2017-05-30 20:30 +0200
Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN Nick Kralevich <nnk@google.com> - 2017-05-30 20:50 +0200
Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN Matt Brown <matt@nmatt.com> - 2017-05-30 21:00 +0200
Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN Daniel Micay <danielmicay@gmail.com> - 2017-05-30 22:30 +0200
Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN Matt Brown <matt@nmatt.com> - 2017-05-31 01:10 +0200
Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN Daniel Micay <danielmicay@gmail.com> - 2017-05-31 01:50 +0200
Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN Matt Brown <matt@nmatt.com> - 2017-05-31 02:00 +0200
Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN Alan Cox <gnomes@lxorguk.ukuu.org.uk> - 2017-05-31 01:00 +0200
Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN Matt Brown <matt@nmatt.com> - 2017-05-31 01:20 +0200
Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN Alan Cox <gnomes@lxorguk.ukuu.org.uk> - 2017-05-31 02:00 +0200
Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN Kees Cook <keescook@chromium.org> - 2017-06-01 04:40 +0200
Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN Alan Cox <gnomes@lxorguk.ukuu.org.uk> - 2017-06-01 15:10 +0200
Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN "Serge E. Hallyn" <serge@hallyn.com> - 2017-06-01 19:20 +0200
Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN Alan Cox <gnomes@lxorguk.ukuu.org.uk> - 2017-06-01 23:30 +0200
Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN Kees Cook <keescook@chromium.org> - 2017-06-01 21:00 +0200
Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN Alan Cox <gnomes@lxorguk.ukuu.org.uk> - 2017-06-01 23:30 +0200
Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN Matt Brown <matt@nmatt.com> - 2017-06-02 16:50 +0200
Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN "Serge E. Hallyn" <serge@hallyn.com> - 2017-06-02 17:40 +0200
Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN Matt Brown <matt@nmatt.com> - 2017-06-02 18:10 +0200
Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN "Serge E. Hallyn" <serge@hallyn.com> - 2017-06-02 19:00 +0200
Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN Matt Brown <matt@nmatt.com> - 2017-06-02 19:40 +0200
Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN "Serge E. Hallyn" <serge@hallyn.com> - 2017-06-02 20:20 +0200
Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN Matt Brown <matt@nmatt.com> - 2017-06-02 21:30 +0200
Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN Kees Cook <keescook@chromium.org> - 2017-06-02 21:30 +0200
Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN Matt Brown <matt@nmatt.com> - 2017-06-02 21:30 +0200
Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN Alan Cox <gnomes@lxorguk.ukuu.org.uk> - 2017-06-02 22:10 +0200
Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN Nick Kralevich <nnk@google.com> - 2017-06-02 22:20 +0200
Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN Matt Brown <matt@nmatt.com> - 2017-06-02 22:50 +0200
Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN Alan Cox <gnomes@lxorguk.ukuu.org.uk> - 2017-06-04 00:10 +0200
Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN Matt Brown <matt@nmatt.com> - 2017-06-04 00:30 +0200
Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN Peter Dolding <oiaohm@gmail.com> - 2017-06-04 05:40 +0200
Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN Casey Schaufler <casey@schaufler-ca.com> - 2017-05-30 17:30 +0200
Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN Matt Brown <matt@nmatt.com> - 2017-05-30 18:10 +0200
Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN Boris Lukashev <blukashev@sempervictus.com> - 2017-06-04 08:30 +0200
Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN James Morris <jmorris@namei.org> - 2017-05-31 04:50 +0200
Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN Matt Brown <matt@nmatt.com> - 2017-05-31 06:20 +0200
Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN Matt Brown <matt@nmatt.com> - 2017-05-30 02:20 +0200
Page 3 of 3 — ← Prev page 1 2 [3]
| From | Peter Dolding <oiaohm@gmail.com> |
|---|---|
| Date | 2017-06-04 05:40 +0200 |
| Subject | Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN |
| Message-ID | <tOuyt-7uy-3@gated-at.bofh.it> |
| In reply to | #1656948 |
On Sun, Jun 4, 2017 at 8:22 AM, Matt Brown <matt@nmatt.com> wrote: > On 06/03/2017 06:00 PM, Alan Cox wrote: >>> >>> TIOCSLCKTRMIOS >> >> >> That one I'm more dubious about >> >>> TIOCSLTC >>> TIOCSSOFTCAR >> >> >> tty_io.c also has a few and n_tty has a couple we'd want. >> >>> >>> would it be overkill to have a sysctl kernel.ttyioctlwhitelist.X where X >>> is one of the ioctls above? >> >> >> Why would anyone want to change the entries on that list >> > > Did you see Serge's proposed solution? I want us to not be talking past > each other. Serge proposed the following: > > | By default, nothing changes - you can use those on your own tty, need > | CAP_SYS_ADMIN against init_user_ns otherwise. > | > | Introduce a new CAP_TTY_PRIVILEGED. > | > | When may_push_chars is removed from the whitelist, you lose the > | ability to use TIOCSTI on a tty - even your own - if you do not have > | CAP_TTY_PRIVILEGED against the tty's user_ns. > > The question is how do you add/remove something from this whitelist? I > assume by add/remove we don't mean that you have to recompile your > kernel to change the whitelist! > > you earlier said you wanted the check to look like this: > > | if (!whitelisted(ioctl) && different_namespace && magic_flag) > > I want to know which namespace you are talking about here. Did you mean > user_namespace? (the namespace I added tracking for in the tty_struct) There are many ways to attempt to cure this problem. They some that are just wrong. Pushing stuff up to CAP_SYS_ADMIN is fairly much always wrong. Using a whitelisted solution does have a downside but to use some application that use TIOCSTI safely I have not had to push application to CAP_SYS_ADMIN. Another question due to the way the exploit work a broken TIOCSTI where push back could be something someone as CAP_SYS_ADMIN run. What I don't know if yet set when ever an application used TIOCSTI to push back chars back into input that this would set input to be flushed on tty disconnect or application termination would this break any applications. So it may be possible to allow applications to freely use TIOCSTI just make sure that anything an application has pushed back into input buffer cannot get to anything else. The thing to remember is most times when applications are controlling other applications they are not pushing data backwards on input.. Question I have is what is valid usage cases of TIOCSTI. Thinking grscecurity got away with pushing this up to CAP_SYS_ADMIN there may not be many. If there is no valid usage of TIOCSTI across applications there is no reason why TIOCSTI cannot be setup to automatically trigger input flushs to prevent TIOCSTI inserted data getting anywhere. . This could be like X11 and it huge number of features where large number were found that no one ever used just was created that way because it was though like it would be useful. My problem here is TIOCSTI might not need a flag at all. TIOCSTI functionality maybe in need of limitations particularly if TIOCSTI push back into input cross from one application to the next has no genuine application usage. So far no one has started that exploited TIOCSTI functionality exists in any genuine application as expected functionality. I cannot find example of where pushing back into input then going to background or dieing/exiting and having that pushed back input processed is done by any genuine application as expected functionality. That is something that could be limited if there is no genuine users and close the door without having to modify existing applications that don't expect to-do that. Its really simple to get focused in on quick fix to problems without asking is the behaviour even required. Peter Dolding
[toc] | [prev] | [next] | [standalone]
| From | Casey Schaufler <casey@schaufler-ca.com> |
|---|---|
| Date | 2017-05-30 17:30 +0200 |
| Subject | Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN |
| Message-ID | <tMRfQ-DG-11@gated-at.bofh.it> |
| In reply to | #1652787 |
On 5/29/2017 8:18 PM, Matt Brown wrote: > On 5/29/17 10:46 PM, Casey Schaufler wrote: >> On 5/29/2017 7:00 PM, Matt Brown wrote: >>> Casey Schaufler, >>> >>> First I must start this off by saying I really appreciate your presentation on >>> LSMs that is up on youtube. I've got a LSM in the works and your talk has >>> helped me a bunch. >> Thank you. Feedback (especially positive) is always appreciated. >> >>> On 5/29/17 8:27 PM, Casey Schaufler wrote: >>>> On 5/29/2017 4:51 PM, Boris Lukashev wrote: >>>>> With all due respect sir, i believe your review falls short of the >>>>> purpose of this effort - to harden the kernel against flaws in >>>>> userspace. Comments along the line of "if <userspace> does it right >>>>> then your patch is pointless" are not relevant to the context of >>>>> securing kernel functions/interfaces. What userspace should do has >>>>> little bearing on defensive measures actually implemented in the >>>>> kernel - if we took the approach of "someone else is responsible for >>>>> that" in military operations, the world would be a much darker and >>>>> different place today. Those who have the luxury of standoff from the >>>>> critical impacts of security vulnerabilities may not take into account >>>>> the fact that peoples lives literally depend on Linux getting a lot >>>>> more secure, and quickly. >>>> You are not going to help anyone with a kernel configuration that >>>> breaks agetty, csh, xemacs and tcsh. The opportunities for using >>>> such a configuration are limited. >>> This patch does not break these programs as you imply. 99% of users of these >>> programs will not be effected. Its not like the TIOCSTI ioctl is a critical >>> part of these programs. >> Most likely not. >> >>> Also as I've stated elsewhere, this is not breaking userspace because this >>> Kconfig/sysctl defaults to n. If someone is using the programs listed above in >>> a way that does utilize an unprivileged call to the TIOCSTI ioctl, they can >>> turn this feature off. >> Default "off" does not mean it doesn't break userspace. It means that it might >> not break userspace in your environment. Or it might, depending on the whim of >> the build tool of the day. >> > By this logic, it seems like any introduced feature which toggles some security > feature could be seen as "breaking userspace." For example: > > 1. Let there exist a LSM X that is set to "off" by default. > (let's say its a simpler type of MAC ;) You picked a bad example ... > 2. There exists an inexperienced user Bob that toggles X to "on". ... which is easy enough, however ... > 3. Bob complains that X has broken userspace because he now cannot access his > SSH key from firefox. ... that's not going to happen. Because the LSM you're referring to requires additional configuration to "break" userspace. That, by the way, was a conscious design choice. Now, I realize that's not the case for some other security modules, but they have things like "permissive mode" to make it easy on accident prone Bob. The analogy, while obvious, is invalid. > build tool's will always have important impacts on a system based on the config > that is used. > > My understanding of the "don't break userspace" rule has always been to not > change existing, userspace facing, APIs/ioctls/system calls/etc. I don't > believe that my patch does this. > >>>>> If this work were not valuable, it wouldnt be an enabled kernel option >>>>> on a massive number of kernels with attack surfaces reduced by the >>>>> compound protections offered by the grsec patch set. >>>> I'll bet you a beverage that 99-44/100% of the people who have >>>> this enabled have no clue that it's even there. And if they did, >>>> most of them would turn it off. >>>> >>> First, I don't know how to parse "99-44/100%" and therefore do not wish to >>> wager a beverage on such confusing odds ;) >> 99.44%. And I loose a *lot* of beverage bets. >> >>> Second, as stated above, this feature is off by default. However, I would expect >>> this sysctl to show up in lists of procedures for hardening linux servers. >> It's esoteric enough that I expect that if anyone got bitten by it >> word would get out and no one would use it thereafter. >> > As we know in the security world, esoteric things can have major a impact. I > have not looked thought all of these, but I imagine most of them could have > been prevented by this patch. > > https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=tiocsti > >>>>> I can't speak for >>>>> the grsec people, but having read a small fraction of the commentary >>>>> around the subject of mainline integration, it seems to me that NAKs >>>>> like this are exactly why they had no interest in even trying - this >>>>> review is based on the cultural views of the kernel community, not on >>>>> the security benefits offered by the work in the current state of >>>>> affairs (where userspace is broken). >>>> A security clamp-down that breaks important stuff is going >>>> to have a tough row to hoe going upstream. Same with a performance >>>> enhancement that breaks things. >>>> >>>>> The purpose of each of these >>>>> protections (being ported over from grsec) is not to offer carte >>>>> blanche defense against all attackers and vectors, but to prevent >>>>> specific classes of bugs from reducing the security posture of the >>>>> system. By implementing these defenses in a layered manner we can >>>>> significantly reduce our kernel attack surface. >>>> Sure, but they have to work right. That's an important reason to do >>>> small changes. A change that isn't acceptable can be rejected without >>>> slowing the general progress. >>>> >>>>> Once userspace catches >>>>> up and does things the right way, and has no capacity for doing them >>>>> the wrong way (aka, nothing attackers can use to bypass the proper >>>>> userspace behavior), then the functionality really does become >>>>> pointless, and can then be removed. >>>> Well, until someone comes along with yet another spiffy feature >>>> like containers and breaks it again. This is why a really good >>>> solution is required, and the one proposed isn't up to snuff. >>>> >>> Can you please state your reasons for why you believe this solution is not "up >>> to snuff?" So far myself and others have given what I believe to be sound >>> responses to any objections to this patch. >> If you can't convince Alan, who know ways more about ttys than anyone >> ought to, it's not up to snuff. >> >>>>> >From a practical perspective, can alternative solutions be offered >>>>> along with NAKs? >>>> They often are, but let's face it, not everyone has the time, >>>> desire and/or expertise to solve every problem that comes up. >>>> >>>>> Killing things on the vine isnt great, and if a >>>>> security measure is being denied, upstream should provide their >>>>> solution to how they want to address the problem (or just an outline >>>>> to guide the hardened folks). >>>> The impact of a "security measure" can exceed the value provided. >>>> That is, I understand, the basis of the NAK. We need to be careful >>>> to keep in mind that, until such time as there is substantial interest >>>> in the sort of systemic changes that truly remove this class of issue, >>>> we're going to have to justify the risk/reward trade off when we try >>>> to introduce a change. >>>> >>>>> On Mon, May 29, 2017 at 6:26 PM, Alan Cox <gnomes@lxorguk.ukuu.org.uk> wrote: >>>>>> On Mon, 29 May 2017 17:38:00 -0400 >>>>>> Matt Brown <matt@nmatt.com> wrote: >>>>>> >>>>>>> This introduces the tiocsti_restrict sysctl, whose default is controlled >>>>>>> via CONFIG_SECURITY_TIOCSTI_RESTRICT. When activated, this control >>>>>>> restricts all TIOCSTI ioctl calls from non CAP_SYS_ADMIN users. >>>>>> Which is really quite pointless as I keep pointing out and you keep >>>>>> reposting this nonsense. >>>>>> >>>>>>> This patch depends on patch 1/2 >>>>>>> >>>>>>> This patch was inspired from GRKERNSEC_HARDEN_TTY. >>>>>>> >>>>>>> This patch would have prevented >>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1411256 under the following >>>>>>> conditions: >>>>>>> * non-privileged container >>>>>>> * container run inside new user namespace >>>>>> And assuming no other ioctl could be used in an attack. Only there are >>>>>> rather a lot of ways an app with access to a tty can cause mischief if >>>>>> it's the same controlling tty as the higher privileged context that >>>>>> launched it. >>>>>> >>>>>> Properly written code allocates a new pty/tty pair for the lower >>>>>> privileged session. If the code doesn't do that then your change merely >>>>>> modifies the degree of mayhem it can cause. If it does it right then your >>>>>> patch is pointless. >>>>>> >>>>>>> Possible effects on userland: >>>>>>> >>>>>>> There could be a few user programs that would be effected by this >>>>>>> change. >>>>>> In other words, it's yet another weird config option that breaks stuff. >>>>>> >>>>>> >>>>>> NAK v7. >>>>>> >>>>>> Alan >>> Thanks, >>> Matt Brown >>>
[toc] | [prev] | [next] | [standalone]
| From | Matt Brown <matt@nmatt.com> |
|---|---|
| Date | 2017-05-30 18:10 +0200 |
| Subject | Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN |
| Message-ID | <tMRSy-16W-7@gated-at.bofh.it> |
| In reply to | #1653317 |
On 5/30/17 11:20 AM, Casey Schaufler wrote: > On 5/29/2017 8:18 PM, Matt Brown wrote: >> On 5/29/17 10:46 PM, Casey Schaufler wrote: >>> On 5/29/2017 7:00 PM, Matt Brown wrote: >>>> Casey Schaufler, >>>> >>>> First I must start this off by saying I really appreciate your presentation on >>>> LSMs that is up on youtube. I've got a LSM in the works and your talk has >>>> helped me a bunch. >>> Thank you. Feedback (especially positive) is always appreciated. >>> >>>> On 5/29/17 8:27 PM, Casey Schaufler wrote: >>>>> On 5/29/2017 4:51 PM, Boris Lukashev wrote: >>>>>> With all due respect sir, i believe your review falls short of the >>>>>> purpose of this effort - to harden the kernel against flaws in >>>>>> userspace. Comments along the line of "if <userspace> does it right >>>>>> then your patch is pointless" are not relevant to the context of >>>>>> securing kernel functions/interfaces. What userspace should do has >>>>>> little bearing on defensive measures actually implemented in the >>>>>> kernel - if we took the approach of "someone else is responsible for >>>>>> that" in military operations, the world would be a much darker and >>>>>> different place today. Those who have the luxury of standoff from the >>>>>> critical impacts of security vulnerabilities may not take into account >>>>>> the fact that peoples lives literally depend on Linux getting a lot >>>>>> more secure, and quickly. >>>>> You are not going to help anyone with a kernel configuration that >>>>> breaks agetty, csh, xemacs and tcsh. The opportunities for using >>>>> such a configuration are limited. >>>> This patch does not break these programs as you imply. 99% of users of these >>>> programs will not be effected. Its not like the TIOCSTI ioctl is a critical >>>> part of these programs. >>> Most likely not. >>> >>>> Also as I've stated elsewhere, this is not breaking userspace because this >>>> Kconfig/sysctl defaults to n. If someone is using the programs listed above in >>>> a way that does utilize an unprivileged call to the TIOCSTI ioctl, they can >>>> turn this feature off. >>> Default "off" does not mean it doesn't break userspace. It means that it might >>> not break userspace in your environment. Or it might, depending on the whim of >>> the build tool of the day. >>> >> By this logic, it seems like any introduced feature which toggles some security >> feature could be seen as "breaking userspace." For example: >> >> 1. Let there exist a LSM X that is set to "off" by default. >> (let's say its a simpler type of MAC ;) > > You picked a bad example ... > >> 2. There exists an inexperienced user Bob that toggles X to "on". > > ... which is easy enough, however ... > >> 3. Bob complains that X has broken userspace because he now cannot access his >> SSH key from firefox. > > ... that's not going to happen. Because the LSM you're referring to requires > additional configuration to "break" userspace. That, by the way, was a conscious > design choice. Now, I realize that's not the case for some other security modules, > but they have things like "permissive mode" to make it easy on accident prone Bob. > > The analogy, while obvious, is invalid. So I may have been a bit sarcastic with my analogy, but my point is that it seems like your definition of "breaking userspace" is too broad and could lead to things getting labeled as breaking userspace that clearly are not. > >> build tool's will always have important impacts on a system based on the config >> that is used. >> >> My understanding of the "don't break userspace" rule has always been to not >> change existing, userspace facing, APIs/ioctls/system calls/etc. I don't >> believe that my patch does this. >> >>>>>> If this work were not valuable, it wouldnt be an enabled kernel option >>>>>> on a massive number of kernels with attack surfaces reduced by the >>>>>> compound protections offered by the grsec patch set. >>>>> I'll bet you a beverage that 99-44/100% of the people who have >>>>> this enabled have no clue that it's even there. And if they did, >>>>> most of them would turn it off. >>>>> >>>> First, I don't know how to parse "99-44/100%" and therefore do not wish to >>>> wager a beverage on such confusing odds ;) >>> 99.44%. And I loose a *lot* of beverage bets. >>> >>>> Second, as stated above, this feature is off by default. However, I would expect >>>> this sysctl to show up in lists of procedures for hardening linux servers. >>> It's esoteric enough that I expect that if anyone got bitten by it >>> word would get out and no one would use it thereafter. >>> >> As we know in the security world, esoteric things can have major a impact. I >> have not looked thought all of these, but I imagine most of them could have >> been prevented by this patch. >> >> https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=tiocsti >> >>>>>> I can't speak for >>>>>> the grsec people, but having read a small fraction of the commentary >>>>>> around the subject of mainline integration, it seems to me that NAKs >>>>>> like this are exactly why they had no interest in even trying - this >>>>>> review is based on the cultural views of the kernel community, not on >>>>>> the security benefits offered by the work in the current state of >>>>>> affairs (where userspace is broken). >>>>> A security clamp-down that breaks important stuff is going >>>>> to have a tough row to hoe going upstream. Same with a performance >>>>> enhancement that breaks things. >>>>> >>>>>> The purpose of each of these >>>>>> protections (being ported over from grsec) is not to offer carte >>>>>> blanche defense against all attackers and vectors, but to prevent >>>>>> specific classes of bugs from reducing the security posture of the >>>>>> system. By implementing these defenses in a layered manner we can >>>>>> significantly reduce our kernel attack surface. >>>>> Sure, but they have to work right. That's an important reason to do >>>>> small changes. A change that isn't acceptable can be rejected without >>>>> slowing the general progress. >>>>> >>>>>> Once userspace catches >>>>>> up and does things the right way, and has no capacity for doing them >>>>>> the wrong way (aka, nothing attackers can use to bypass the proper >>>>>> userspace behavior), then the functionality really does become >>>>>> pointless, and can then be removed. >>>>> Well, until someone comes along with yet another spiffy feature >>>>> like containers and breaks it again. This is why a really good >>>>> solution is required, and the one proposed isn't up to snuff. >>>>> >>>> Can you please state your reasons for why you believe this solution is not "up >>>> to snuff?" So far myself and others have given what I believe to be sound >>>> responses to any objections to this patch. >>> If you can't convince Alan, who know ways more about ttys than anyone >>> ought to, it's not up to snuff. >>> >>>>>> >From a practical perspective, can alternative solutions be offered >>>>>> along with NAKs? >>>>> They often are, but let's face it, not everyone has the time, >>>>> desire and/or expertise to solve every problem that comes up. >>>>> >>>>>> Killing things on the vine isnt great, and if a >>>>>> security measure is being denied, upstream should provide their >>>>>> solution to how they want to address the problem (or just an outline >>>>>> to guide the hardened folks). >>>>> The impact of a "security measure" can exceed the value provided. >>>>> That is, I understand, the basis of the NAK. We need to be careful >>>>> to keep in mind that, until such time as there is substantial interest >>>>> in the sort of systemic changes that truly remove this class of issue, >>>>> we're going to have to justify the risk/reward trade off when we try >>>>> to introduce a change. >>>>> >>>>>> On Mon, May 29, 2017 at 6:26 PM, Alan Cox <gnomes@lxorguk.ukuu.org.uk> wrote: >>>>>>> On Mon, 29 May 2017 17:38:00 -0400 >>>>>>> Matt Brown <matt@nmatt.com> wrote: >>>>>>> >>>>>>>> This introduces the tiocsti_restrict sysctl, whose default is controlled >>>>>>>> via CONFIG_SECURITY_TIOCSTI_RESTRICT. When activated, this control >>>>>>>> restricts all TIOCSTI ioctl calls from non CAP_SYS_ADMIN users. >>>>>>> Which is really quite pointless as I keep pointing out and you keep >>>>>>> reposting this nonsense. >>>>>>> >>>>>>>> This patch depends on patch 1/2 >>>>>>>> >>>>>>>> This patch was inspired from GRKERNSEC_HARDEN_TTY. >>>>>>>> >>>>>>>> This patch would have prevented >>>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1411256 under the following >>>>>>>> conditions: >>>>>>>> * non-privileged container >>>>>>>> * container run inside new user namespace >>>>>>> And assuming no other ioctl could be used in an attack. Only there are >>>>>>> rather a lot of ways an app with access to a tty can cause mischief if >>>>>>> it's the same controlling tty as the higher privileged context that >>>>>>> launched it. >>>>>>> >>>>>>> Properly written code allocates a new pty/tty pair for the lower >>>>>>> privileged session. If the code doesn't do that then your change merely >>>>>>> modifies the degree of mayhem it can cause. If it does it right then your >>>>>>> patch is pointless. >>>>>>> >>>>>>>> Possible effects on userland: >>>>>>>> >>>>>>>> There could be a few user programs that would be effected by this >>>>>>>> change. >>>>>>> In other words, it's yet another weird config option that breaks stuff. >>>>>>> >>>>>>> >>>>>>> NAK v7. >>>>>>> >>>>>>> Alan >>>> Thanks, >>>> Matt Brown >>>> >
[toc] | [prev] | [next] | [standalone]
| From | Boris Lukashev <blukashev@sempervictus.com> |
|---|---|
| Date | 2017-06-04 08:30 +0200 |
| Subject | Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN |
| Message-ID | <tOxcZ-Xi-9@gated-at.bofh.it> |
| In reply to | #1652748 |
On Mon, May 29, 2017 at 8:27 PM, Casey Schaufler <casey@schaufler-ca.com> wrote: > On 5/29/2017 4:51 PM, Boris Lukashev wrote: >> With all due respect sir, i believe your review falls short of the >> purpose of this effort - to harden the kernel against flaws in >> userspace. Comments along the line of "if <userspace> does it right >> then your patch is pointless" are not relevant to the context of >> securing kernel functions/interfaces. What userspace should do has >> little bearing on defensive measures actually implemented in the >> kernel - if we took the approach of "someone else is responsible for >> that" in military operations, the world would be a much darker and >> different place today. Those who have the luxury of standoff from the >> critical impacts of security vulnerabilities may not take into account >> the fact that peoples lives literally depend on Linux getting a lot >> more secure, and quickly. > > You are not going to help anyone with a kernel configuration that > breaks agetty, csh, xemacs and tcsh. The opportunities for using > such a configuration are limited. > First off, thank you for the clear and rational responses - newbie status in these upstreaming/kernel matters has a bit of a steep learning curve. I would however, have to disagree with the above in that there is a very large number of purpose built Linux systems in play, home routers being a good example, which effectively retain the same security posture over their lifetime in an increasingly hostile operating environment. Mitigation at every tier of the attack cycle is desirable as a (configurable) default such as to at least reduce the impact of compromise (they may leak memory containing the admin cred for the web ui via some protocol error, but dont get shells, local privs, and raw device access). Then there are all the servers out there which would benefit from this, as they dont use those components but do expose TTYs to dangerous consumers, and even the workstations in a similar boat where they dont depend on faulty consumers but are operated by faulty users. Devil's in the details right? Ideally, if properly designed with input from greybeards, faults can be mostly nullified and edge cases addressed with adjacent maintainers. >> If this work were not valuable, it wouldnt be an enabled kernel option >> on a massive number of kernels with attack surfaces reduced by the >> compound protections offered by the grsec patch set. > > I'll bet you a beverage that 99-44/100% of the people who have > this enabled have no clue that it's even there. And if they did, > most of them would turn it off. > Wouldn't dream of taking that bet - the vast majority of Linux users dont even know they're Linux users :). Disagree with the latter part though, the majority of people rely on the appropriate organs of society (military, police, security-focused devs) to provide for their safety; they not only take for granted but largely abide by the constraints placed by those in the know such as to ensure that safety. A cynical example being that you may not know exactly what the stuff in that hazmat-labled container will do to you (may make you into Wolverine, or melt your bones), but you're not likely to open it and take a sip - you trust the people who sealed it to know enough of the details to have made that decision. Implementing changes like this (properly scoped and implemented, as the refinement process seems to be doing) makes a lot of sense top-down as it forces consumers to do things the right way instead of waiting for them before adopting a useful function. >> I can't speak for >> the grsec people, but having read a small fraction of the commentary >> around the subject of mainline integration, it seems to me that NAKs >> like this are exactly why they had no interest in even trying - this >> review is based on the cultural views of the kernel community, not on >> the security benefits offered by the work in the current state of >> affairs (where userspace is broken). > > A security clamp-down that breaks important stuff is going > to have a tough row to hoe going upstream. Same with a performance > enhancement that breaks things. > Back to the newbie status bit, i've read and heard (in varying degrees of satisfaction and frustration) that upstream makes it hard to adopt significant changes as a culture. Obviously there are practical concerns around compatibility, but there must be some avenue to have a clear and rational discussion with Olympus about inducing a well planned and short period of churn to affect changes which will greatly extend the iconic notion of systems running stable and safe for years at a time... In practical terms, distributions ship tons of patches for kernel bugs faster than you can reload a blunderbuss. While that is good practice, and should continue, it results in constant operating efforts on the parts of the consumer having to "manage their updates" since the bug isn't restricted in access vectors or efficacy by a global defensive measure, but requires direct patching to mitigate. Compliance beholden systems, which tend to be in the critical path, suffer obligatory burdens from the status quo - find me a hospital IT security manager who hasn't thought of running (himself or his boss) head first through his office window since the start of the quarter, and i'll betcha he started work Friday. A "security clamp-down" would be great if it were well coordinated with the ecosystem such as to have bugs found by compile-time approaches immediately addressed by their owning maintainers, quickly spread use of read-only and randomized structures, memory allocations, or whatever other defenses are implemented at the core/LSM infrastructure tiers. Once the large changes are in, things go back to business-as-usual, but without the ops engineers being restricted to eating with dull plastic spoons. >> The purpose of each of these >> protections (being ported over from grsec) is not to offer carte >> blanche defense against all attackers and vectors, but to prevent >> specific classes of bugs from reducing the security posture of the >> system. By implementing these defenses in a layered manner we can >> significantly reduce our kernel attack surface. > > Sure, but they have to work right. That's an important reason to do > small changes. A change that isn't acceptable can be rejected without > slowing the general progress. > Understood and agreed - getting the right scope and constraints for the job is imperative for proper design and implementation of the solution. As i'm reading the evolution of this thread i'm learning how submissions evolve to fit the needs defined by members. Sort of rare to see a process involving multiple participants these days which hasn't devolved into a sandy goat-roping procedure. >> Once userspace catches >> up and does things the right way, and has no capacity for doing them >> the wrong way (aka, nothing attackers can use to bypass the proper >> userspace behavior), then the functionality really does become >> pointless, and can then be removed. > > Well, until someone comes along with yet another spiffy feature > like containers and breaks it again. This is why a really good > solution is required, and the one proposed isn't up to snuff. > >> >From a practical perspective, can alternative solutions be offered >> along with NAKs? > > They often are, but let's face it, not everyone has the time, > desire and/or expertise to solve every problem that comes up. > >> Killing things on the vine isnt great, and if a >> security measure is being denied, upstream should provide their >> solution to how they want to address the problem (or just an outline >> to guide the hardened folks). > > The impact of a "security measure" can exceed the value provided. > That is, I understand, the basis of the NAK. We need to be careful > to keep in mind that, until such time as there is substantial interest > in the sort of systemic changes that truly remove this class of issue, > we're going to have to justify the risk/reward trade off when we try > to introduce a change. > Here i again, have to respectfully disagree. Waiting on "significant interest" to patch their workstations and servers is what got a chunk of the world looking for backups and coughing up bitcoins recently. If there is a viable threat model, it should be addressed proactively, as opposed to potential operating bugs which are shaken out in the course of ops (which is how i understand current triage to work for bugs - once its found, not potentially because conditions could create it). Security as an afterthought can be seen as a form of complacency, and as we've all read - "complacency kills." >> >> On Mon, May 29, 2017 at 6:26 PM, Alan Cox <gnomes@lxorguk.ukuu.org.uk> wrote: >>> On Mon, 29 May 2017 17:38:00 -0400 >>> Matt Brown <matt@nmatt.com> wrote: >>> >>>> This introduces the tiocsti_restrict sysctl, whose default is controlled >>>> via CONFIG_SECURITY_TIOCSTI_RESTRICT. When activated, this control >>>> restricts all TIOCSTI ioctl calls from non CAP_SYS_ADMIN users. >>> Which is really quite pointless as I keep pointing out and you keep >>> reposting this nonsense. >>> >>>> This patch depends on patch 1/2 >>>> >>>> This patch was inspired from GRKERNSEC_HARDEN_TTY. >>>> >>>> This patch would have prevented >>>> https://bugzilla.redhat.com/show_bug.cgi?id=1411256 under the following >>>> conditions: >>>> * non-privileged container >>>> * container run inside new user namespace >>> And assuming no other ioctl could be used in an attack. Only there are >>> rather a lot of ways an app with access to a tty can cause mischief if >>> it's the same controlling tty as the higher privileged context that >>> launched it. >>> >>> Properly written code allocates a new pty/tty pair for the lower >>> privileged session. If the code doesn't do that then your change merely >>> modifies the degree of mayhem it can cause. If it does it right then your >>> patch is pointless. >>> >>>> Possible effects on userland: >>>> >>>> There could be a few user programs that would be effected by this >>>> change. >>> In other words, it's yet another weird config option that breaks stuff. >>> >>> >>> NAK v7. >>> >>> Alan >> >> >
[toc] | [prev] | [next] | [standalone]
| From | James Morris <jmorris@namei.org> |
|---|---|
| Date | 2017-05-31 04:50 +0200 |
| Subject | Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN |
| Message-ID | <tN1RT-7cZ-3@gated-at.bofh.it> |
| In reply to | #1652745 |
On Mon, 29 May 2017, Boris Lukashev wrote: > With all due respect sir, i believe your review falls short of the > purpose of this effort - to harden the kernel against flaws in > userspace. Which effort? Kernel self protection is about protecting against flaws in the kernel. See: https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project "This project starts with the premise that kernel bugs have a very long lifetime, and that the kernel must be designed in ways to protect against these flaws." We need to avoid conflating: - hardening the kernel against attack; and - modifying the kernel to try and harden userspace. These patches are the latter, and the case for them is not as straightforward. - James -- James Morris <jmorris@namei.org>
[toc] | [prev] | [next] | [standalone]
| From | Matt Brown <matt@nmatt.com> |
|---|---|
| Date | 2017-05-31 06:20 +0200 |
| Subject | Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN |
| Message-ID | <tN3gZ-8hk-1@gated-at.bofh.it> |
| In reply to | #1653792 |
On 05/30/2017 10:48 PM, James Morris wrote: > On Mon, 29 May 2017, Boris Lukashev wrote: > >> With all due respect sir, i believe your review falls short of the >> purpose of this effort - to harden the kernel against flaws in >> userspace. > > Which effort? Kernel self protection is about protecting against flaws in > the kernel. > > See: > https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project > > "This project starts with the premise that kernel bugs have a very long > lifetime, and that the kernel must be designed in ways to protect against > these flaws." > > We need to avoid conflating: > > - hardening the kernel against attack; and > - modifying the kernel to try and harden userspace. > > These patches are the latter, and the case for them is not as > straightforward. > > > - James > I agree that these patches aren't kernel self protection and I don't believe I have claimed they are such a thing. These patches I'm presenting are more akin to ptrace protections that are found in Yama.
[toc] | [prev] | [next] | [standalone]
| From | Matt Brown <matt@nmatt.com> |
|---|---|
| Date | 2017-05-30 02:20 +0200 |
| Subject | Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN |
| Message-ID | <tMD3b-7K6-3@gated-at.bofh.it> |
| In reply to | #1652732 |
On 5/29/17 6:26 PM, Alan Cox wrote: > On Mon, 29 May 2017 17:38:00 -0400 > Matt Brown <matt@nmatt.com> wrote: > >> This introduces the tiocsti_restrict sysctl, whose default is controlled >> via CONFIG_SECURITY_TIOCSTI_RESTRICT. When activated, this control >> restricts all TIOCSTI ioctl calls from non CAP_SYS_ADMIN users. > > Which is really quite pointless as I keep pointing out and you keep > reposting this nonsense. > >> >> This patch depends on patch 1/2 >> >> This patch was inspired from GRKERNSEC_HARDEN_TTY. >> >> This patch would have prevented >> https://bugzilla.redhat.com/show_bug.cgi?id=1411256 under the following >> conditions: >> * non-privileged container >> * container run inside new user namespace > > And assuming no other ioctl could be used in an attack. Only there are > rather a lot of ways an app with access to a tty can cause mischief if > it's the same controlling tty as the higher privileged context that > launched it. Can you give me an example of another ioctl that you can abuse to practically gain code execution in the privileged context? Saying that the child process could "cause mischief" is a bit vague. > > Properly written code allocates a new pty/tty pair for the lower > privileged session. If the code doesn't do that then your change merely > modifies the degree of mayhem it can cause. If it does it right then your > patch is pointless. > >> Possible effects on userland: >> >> There could be a few user programs that would be effected by this >> change. > > In other words, it's yet another weird config option that breaks stuff. > It doesn't break anything because it is default n. People that enable this option will understand they are disabling the tiocsti ioctl for non privileged processes. > > NAK v7. Rather than a NAK, could you explain how you would solve this problem in a way that we can protect userspace from shooting itself in the foot. See CVE lookup: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=tiocsti Matt
[toc] | [prev] | [standalone]
Page 3 of 3 — ← Prev page 1 2 [3]
Back to top | Article view | linux.kernel
csiph-web