linux-kernel - Re: [PATCH v3 2/2] tty: Allow TIOCSTI to be disabled

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHC9VhQzSSV30nDpq2q3pNjLDygu_aAsQWiNWuGBB0bphc9kBA@mail.gmail.com>
Date:   Tue, 27 Jun 2023 20:21:03 -0400
From:   Paul Moore <paul@...l-moore.com>
To:     Samuel Thibault <samuel.thibault@...-lyon.org>,
        Kees Cook <kees@...nel.org>, Kees Cook <keescook@...omium.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jirislaby@...nel.org>,
        Simon Brand <simon.brand@...tadigitale.de>,
        linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org,
        Dave@...lke.cc
Subject: Re: [PATCH v3 2/2] tty: Allow TIOCSTI to be disabled

On Tue, Jun 27, 2023 at 5:50 PM Samuel Thibault
<samuel.thibault@...-lyon.org> wrote:
> Samuel Thibault, le dim. 25 juin 2023 17:56:25 +0200, a ecrit:
> > Samuel Thibault, le mer. 28 déc. 2022 21:57:26 +0100, a ecrit:
> > > Can we perhaps just introduce a CAP_TIOCSTI that the brltty daemon would
> > > be able to use? We could even make it only allow TIOCSTI on the linux
> > > console (tty->ops == con_ops).
> >
> > *Please* comment on this so we can progress. ATM people are
> > advising each other to set dev.tty.legacy_tiocsti=1, which is just
> > counter-productive in terms of security...
>
> People are even discussing adding that configuration to the brltty
> package, which e.g. on ubuntu is installed by default, and thus
> defeating completely the security measure by default...
>
> Please do contribute to the discussion so we can fix this.

Hi Samuel,

I'm sorry to hear that this is impacting Braille terminals, but I do
believe there are solutions in place which would allow affected users
to re-enable TIOCSTI system-wide via the sysctl and then selectively
allow access to the terminal applications.  However, I do believe they
would all require some additional work on the distro/user's part if
the user didn't want to continue to allow system-wide access to
TIOCSTI.

The first thing that comes to mind is an Android-esque filtering that
Kees already mentioned in the commit itself.  I'm not an Android
expert, but based on the linked "ioctl_macros" file in the Android
source, it looks like Android is leveraging the SELinux ioctl extended
permission functionality to limit access to TIOCSTI.  I'm not sure
what experience you have with SELinux, but if you have some
understanding of SELinux policy the documentation below might help you
get started playing with this:

* https://github.com/SELinuxProject/selinux-notebook/blob/main/src/xperm_rules.md

Another option to restrict TIOCSTI once it has been re-enabled
system-wide would be to leverage seccomp to block `ioctl(..., TIOCSTI,
...)`.  Sadly, I don't think one would be able to use systemd's
existing seccomp filtering as it doesn't support syscall parameters,
but I imagine with some work one could add some ioctl smarts to the
systemd seccomp code and/or use an existing seccomp sandboxing tool to
effectively remove TIOCSTI.  Using libseccomp, a simple filter would
look something like this (untested pseudocode, you've been warned):

  ctx = seccomp_init(SCMP_ACT_ALLOW);
  seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EIO), SCMP_SYS(ioctl), 1,
SCMP_A1(TIOCSTI));

I'm sure there are some other good ideas that aren't coming to mind
right now, but I tend to think that the solutions to this are going to
be up in userspace.

-- 
paul-moore.com