161–170 of 287 posts
As someone who has been using linux quite happily on the desktop for more than 20 years now, I have to say it remains an eternal experiment, feature wise as well as security wise.
Local root privilege escalation is mostly irrelevant these days. It’s only useful as part of an exploit chain, really. It’s not like shell servers are still around.
Local privesc, don't care. If anyone still thinks that they can draw a security boundary anywhere with a shared kernel, they should really look at kernel CVE database (and be horrified). For every fancy titled exploit there are twenty that you've never heard of. You can sort of do it if you carefully structure your program to restrict syscall use and then use some minimal and well audited syscall filtering layer to h…
https://xkcd.com/1200/
Earlier quoted context omitted.
IPC ?
The GP doesn't understand the vulnerability: https://cdn2.qualys.com/2025/06/17/suse15-pam-udisks-lpe.txt Instead of using something standard like environment variables, pam has a special "pam_env" that contains facts about the user session that it apparently trusts. Users can override pam_env settings by writing to hidden file in ~. So, this exploit chain is more accurately described as "yet another example of utili…
The only safe way to use pam_env's `user_readenv` parameter is as the final rule of `type=session`. This behaves as you'd expect, affecting the child process only.
It appears that openSUSE enables the option for other rule types (auth and/or account), in which case it affects the parent process as well. Oops!
For the record, user_readenv has been disabled since:
commit 4c430f6f8391555bb1b7b78991afb20d35228efc
Author: Tomas Mraz
Date: Mon Oct 11 14:24:30 2010 +0000
Relevant BUGIDs:
Purpose of commit: bugfix
Commit summary:
---------------
2010-10-11 Tomas Mraz
* modules/pam_env/pam_env.c: Change default for user_readenv to 0.
* modules/pam_env/pam_env.8.xml: Document the new default for user_readenv.
Could someone describe what 'allow_active' privileges is on Linux?
Local privesc, don't care. If anyone still thinks that they can draw a security boundary anywhere with a shared kernel, they should really look at kernel CVE database (and be horrified). For every fancy titled exploit there are twenty that you've never heard of. You can sort of do it if you carefully structure your program to restrict syscall use and then use some minimal and well audited syscall filtering layer to h…
Yet people use container based isolation all the time in practice and the sky doesn't fall. Also, every security domain in an Android systems shares a kernel, yet Android is one of the most secure systems out there. Sure, it uses tons of SELinux, but so what? It still has a shared kernel, and a quite featureful one at that. I don't buy the idea that we can't do intra-kernel security isolation and so we shouldn't care…
Local privesc, don't care. If anyone still thinks that they can draw a security boundary anywhere with a shared kernel, they should really look at kernel CVE database (and be horrified). For every fancy titled exploit there are twenty that you've never heard of. You can sort of do it if you carefully structure your program to restrict syscall use and then use some minimal and well audited syscall filtering layer to h…
Yet people use container based isolation all the time in practice and the sky doesn't fall. Also, every security domain in an Android systems shares a kernel, yet Android is one of the most secure systems out there. Sure, it uses tons of SELinux, but so what? It still has a shared kernel, and a quite featureful one at that. I don't buy the idea that we can't do intra-kernel security isolation and so we shouldn't care…
Earlier quoted context omitted.
Wouldn't Android's kernel have most of the hardening steps / disabled features described in GP's comment?
No. Things like eBPF, strace, and packet filtering are enabled. Android uses SELinux and other facilities to limit the amount of code the kernel will allow to access these features. Big difference from their being compiled out of the kernel entirely as the OP suggests is necessary.
Local privesc, don't care. If anyone still thinks that they can draw a security boundary anywhere with a shared kernel, they should really look at kernel CVE database (and be horrified). For every fancy titled exploit there are twenty that you've never heard of. You can sort of do it if you carefully structure your program to restrict syscall use and then use some minimal and well audited syscall filtering layer to h…
Yet people use container based isolation all the time in practice and the sky doesn't fall. Also, every security domain in an Android systems shares a kernel, yet Android is one of the most secure systems out there. Sure, it uses tons of SELinux, but so what? It still has a shared kernel, and a quite featureful one at that. I don't buy the idea that we can't do intra-kernel security isolation and so we shouldn't care…
Earlier quoted context omitted.
Yet people use container based isolation all the time in practice and the sky doesn't fall. Also, every security domain in an Android systems shares a kernel, yet Android is one of the most secure systems out there. Sure, it uses tons of SELinux, but so what? It still has a shared kernel, and a quite featureful one at that. I don't buy the idea that we can't do intra-kernel security isolation and so we shouldn't care…
If you weren't aware, containers aren't a security boundary. Things like bubblewrap are.
Local privesc, don't care. If anyone still thinks that they can draw a security boundary anywhere with a shared kernel, they should really look at kernel CVE database (and be horrified). For every fancy titled exploit there are twenty that you've never heard of. You can sort of do it if you carefully structure your program to restrict syscall use and then use some minimal and well audited syscall filtering layer to h…
Looking at the raw number of CVEs is not very meaningful