[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 1 Jun 2017 11:46:51 -0700
From: Kees Cook <keescook@...omium.org>
To: lazytyped <lazytyped@...il.com>
Cc: "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>
Subject: Re: Re: [PATCH v7 2/2] security: tty: make TIOCSTI
ioctl require CAP_SYS_ADMIN
On Thu, Jun 1, 2017 at 12:12 AM, lazytyped <lazytyped@...il.com> wrote:
>
>
> On 6/1/17 4:35 AM, Kees Cook wrote:
>>
>> I still cannot wrap my head around why providing users with a
>> protection is a bad thing. Yes, the other tty games are bad, but this
>> fixes a specific and especially bad case that is easy to kill. It's
>> got a Kconfig and a sysctl. It's not on by default. This protects the
>> common case of privileged ttys that aren't attached to consoles, etc,
>> so while the framebuffer thing is an issue, it's not always an issue,
>> etc.
>
> There are a couple of reasons for that:
>
> First of all, a protection is extra cost, in terms of maintenance, knowledge
> (a new knob) and compatibility. That extra cost may sound minimal, but adds
> up pretty quickly. If the protection is "easily" bypassable (that is, today
> we use TIOCSTI, tomorrow we use something else in the same path), then that
> extra cost/complexity stays for no good reason. Feature creep is a real
> issue, in security, IMHO - it's not a 'number of features' game.
Yes, absolutely. But the trouble tends to be around "poor initial
design" userspace APIs that need work-arounds to make them safe. These
cases are relatively rare, luckily, so there's not much actual
"slippery slope" for adding those kinds of protections. As for
bypassing, besides Alan's physical-console-specific issues, I haven't
seen anyone point out things with privileged TTYs that are still an
escalation path when TIOCSTI is unavailable.
So, the way I see it, this is a fix for a bad API that keeps being
coded poorly in userspace that, while it doesn't fix all physical
console attacks, does block the specific issue introduced by TIOCSTI.
And since there are legit users of TIOCSTI we can't just remove it,
since some people want the functionality over the risk. Hence, a
sysctl.
All of the reasoning here seems to match the link restrictions from 5
years ago: a crappy API (sticky bit) is not handled by userspace (open
/tmp/$$!) and people get attacked. The solution was a sysctl to enable
the link restrictions that killed the entire class of the common
attack (though it didn't solve especially egregious bad uses, much
like the TIOCSTI fix). Every distro enabled the sysctl, and, while the
data is noisy, looking a CVEs matching "/tmp symlink", the numbers
drop from 2013 and later (with none yet for 2017).
> Second, stuff that is delivered off by default tends to rot. I don't work on
> Linux, but generally try really hard to not add something that is not ON by
> default at least for a small number of things. Stuff inevitably breaks, and
> it's extra cost.
> To me, a protection that needs to be off by default, raises a red flag. I
> know Linux has a somewhat different philosophy (centered around the kernel
> config that each distribution pieces together and ships), so mileage
> probably varies there.
Totally agreed in general about the default-off, but the Linux
ecosystem is a weird one: Linus has mandated that the kernel can never
break userspace by default, effectively freeing upstream developers
from the responsibility of dealing with such breakage. However,
distros can have their own set of defaults. In many of the
security-sensitive areas, distros turn things on by default. As
mentioned above, link restrictions were enabled by default on distros
(some even before it was upstream), as well as things like
CONFIG_DEBUG_RODATA (before it was finally made mandatory, a decade
later), CONFIG_HARDENED_USERCOPY, etc.
This is the evolution of Linux security defenses: first it has to
exist (but default-off), then everyone gets comfortable with it being
enabled because distros turn it on, then everyone gets frustrated that
it's not default-on in the kernel and changes it there too, either by
identifying improvements to allow it on-by-default or just having a
flag-day. An example of the former might be the ancient progression of
/proc/self/maps protections (on-show sysctl in 2.6.22, on-open mm
check in 2.6.24, drop sysctl in 2.6.27). For the latter, noted above,
CONFIG_DEBUG_RODATA (now CONFIG_STRICT_KERNEL_RWX) is a good example
where it was just decided, finally, to make it mandatory (on x86 and
arm64 so far).
> I don't have enough skills to comment about all the possible TTY attacks and
> quirks, but I think I understand where Alan comes from.
Yeah, agreed. I certainly don't claim it solves all the TTY risks, but
it closes the door on a big one. That kind of change has real-world
benefits, and we have decades of evidence to show that just saying
"fix it in userspace" is not going to protect anyone.
-Kees
--
Kees Cook
Pixel Security
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
