Messages in this thread | | | From | Paul Moore <> | Date | Tue, 27 Jun 2023 20:21:03 -0400 | 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@ens-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
| |