We can restrict this further with our own kernel patch if you want, following the “untrusted root user” idea.
1 Like
I cannot review kernel patches since I don’t speak C, let alone understand the kernel code good enough. And I shouldn’t carry such a patch guessing “looks and works good enough” approach. Reason, such an approach could lead to a similar situation as Debian/OpenSSL Fiasco. See Lessons from the Debian/OpenSSL Fiasco.
Therefore, please discuss kernel patches please with upstream: kernel.org; Linux Hardened; Debian.
2 Likes
It’s really simple. It just makes any TIOCSTI call exit with ENODEV (“No such device”) if CONFIG_TIOCSTI_DISABLE is set.
This won’t lead to that. TIOCSTI is a known security risk and is rarely used and when it is used, it’s not for anything important like crypto. OpenBSD has even removed it entirely 'CVS: cvs.openbsd.org: src' - MARC
Upstream will never accept this. They instantly shot down the patch to restrict it to CAP_SYS_ADMIN LKML: Alan Cox: Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN
A patch to remove it entirely is never going to happen.
1 Like
What about Linux Hardened? They might be interested to take the patch?
1 Like
They already restrict it to CAP_SYS_ADMIN and probably won’t want to restrict it further,
1 Like
Then if/once we re-compile the kernel / use linux hardened, we’d also “just use CAP_SYS_ADMIN”. Good enough?
Perhaps just suggest it to them? Let’s see what they say. Since the patch is already done (looks like “90%” of the work), would be good to go a bit further and suggest it to them. Even if they say no, someone might look at the code and have a useful comment. Even in case of no comment could mean someone had a look and didn’t have anything negative to say. Then also we could know their reaction and wouldn’t need to assume it.
Also this seems rushing far ahead. The way I see it:
- figure out how to automatically compile the kernel package on user’s machine during APT upgrades using Debian stock kernel at all
- do the same with Linux Hardened (I didn’t manage yet to use Debian’s packaging files in combination with Linux Hardened.)
- go beyond Linux Hardened, think about becoming even safer than Linux Hardened
Looks like we’re discussing 3) while steps 1) and 2) are far away.
1 Like
It would be alright but allows the root user to use TIOCSTI to compromise applications which might not be good within an untrusted root threat model (we’d also need to restrict ptrace from root and some other things).
The linux-hardened patches have tons of issues with the debian kernel sources. I’ve tried to fix it but it still wouldn’t work so I gave up (might try again some time though).
We should stay as close to the main linux-hardened patch set as possible and try to get it to work for us. I’m already planning on submitting patches like Harden module auto-loading by madaidan · Pull Request #19 · anthraxx/linux-hardened · GitHub
1 Like