Linus Torvalds Approves New Kernel 'Lockdown' Feature (zdnet.com) 86
"After years of countless reviews, discussions, and code rewrites, Linus Torvalds approved on Saturday a new security feature for the Linux kernel, named 'lockdown'," reports ZDNet:
The new feature will ship as a LSM (Linux Security Module) in the soon-to-be-released Linux kernel 5.4 branch, where it will be turned off by default; usage being optional due to the risk of breaking existing systems. The new feature's primary function will be to strengthen the divide between userland processes and kernel code by preventing even the root account from interacting with kernel code -- something that it's been able to do, by design, until now.
When enabled, the new "lockdown" feature will restrict some kernel functionality, even for the root user, making it harder for compromised root accounts to compromise the rest of the OS... "When enabled, various pieces of kernel functionality are restricted," said Linus Torvalds, Linux kernel creator, and the one who put the final stamp of approval on the module yesterday. This includes restricting access to kernel features that may allow arbitrary code execution via code supplied by userland processes; blocking processes from writing or reading /dev/mem and /dev/kmem memory; block access to opening /dev/port to prevent raw port access; enforcing kernel module signatures; and many more others, detailed here.
When enabled, the new "lockdown" feature will restrict some kernel functionality, even for the root user, making it harder for compromised root accounts to compromise the rest of the OS... "When enabled, various pieces of kernel functionality are restricted," said Linus Torvalds, Linux kernel creator, and the one who put the final stamp of approval on the module yesterday. This includes restricting access to kernel features that may allow arbitrary code execution via code supplied by userland processes; blocking processes from writing or reading /dev/mem and /dev/kmem memory; block access to opening /dev/port to prevent raw port access; enforcing kernel module signatures; and many more others, detailed here.
This is like saying (Score:3)
It is a little concerning that there is yet another security ring, but we already have so many that that argument has been lost. Elegance is gone (and yet another layer of security won't make things secure).
Re: (Score:1)
Was it to keep up with CPU, GPU changes?
Who still makes a great OS that is secure?
Re: This is like saying (Score:3)
Re:This is like saying (Score:4, Interesting)
This is like saying "suck it" to GRSecurity. Not that GRSecurity was ever secure, but that's a different question.
It is a little concerning that there is yet another security ring, but we already have so many that that argument has been lost. Elegance is gone (and yet another layer of security won't make things secure).
Well, it seems like good news to me, but, as with any new feature, I will wait for a while before using it to let others test it. Good decision to disable it by default too.
Regarding GRSecurity, I am not sure it is like saying "suck it" to them, in the short term at least. In fact, SELinux , AppArmor, Grsecurity , etc. will probably use that new feature while adding on top of it. Nevertheless, I have to admit that this will cause them to reevaluate the pertinence of their existence in the long term.
A much simpler use case parallel would be Trumpet Winsock that eventually went dead when Microsoft finally realized that they had to implement an IP stack themselves natively. This was a funny era where people were trying to compete the Internet and had other plans, Microsoft included . The French government even deployed Minitel to compete the Internet and it eventually went dead as well.
https://en.wikipedia.org/wiki/... [wikipedia.org]
https://en.wikipedia.org/wiki/... [wikipedia.org]
Re: This is like saying (Score:3)
Re: (Score:2)
"Microservices are just a distributed form of OOP".
Oh dear.
"My First Law of Distributed Object Design: Don't distribute your objects".
- Martin Fowler, https://www.martinfowler.com/b... [martinfowler.com]
Re: (Score:2)
Re:This is like saying (Score:4, Interesting)
The public Internet wasn't really a thing when Minitel began roll-out in 1980 - there were experimental IP connections between universities, but not much else. Home computers available at the time would have had a hard time running a full IP stack. There were lots of dial-up information services before the Internet really took hold in the mid '90s. You can't really fault France Telecom for rolling out a service that was useful at the time, and continued to be for over a decade.
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
Yes, but that was using a remote shell account (which is what some early US ISPs had as their main offering), or like USENET. When home computers got powerful enough to really have even a basic IP stack was when things started taking off I think, as you could have local applications.
I find it somewhat ironic that Microsoft dragged their feet so long when it was clear that this was the way networking was going to go. The competing Windows networking solutions were clearly designed and intended for tiny netw
Re: (Score:3)
A much simpler use case parallel would be Trumpet Winsock that eventually went dead when Microsoft finally realized that they had to implement an IP stack themselves natively.
Microsoft had their own IP stack for Windows 3.1, but Trumpet (and other winsocks) kept going throughout its lifespan because users didn't know it existed for the most part. The fastest stack for Windows 3.1 was TGV's. TGV was working on a high performance stack for Windows 95 (even though it came with a stack, it wasn't very good) when they were bought out by Cisco and turned into a cable modem dev lab.
Re: (Score:2)
I was thinking it sounds an awful lot like what Microsoft introduced with Windows Vista, and refined to its current state in Windows 10.
Re: (Score:2)
I was thinking the same thing. This sounds a bit like UAC.
Isn't UAC the opposite, more like sudo? (Score:2)
Can UAC actually do anything remotely like this, because I thought it was the opposite. I thought UAC allowed you to do Administrator things while logged in as a non-admin user, by popping up a dialog that asks for the Administrator password.
Which, btw, provides a fun opportunity. Write a little script that pops up a dialog that looks like the UAC dialog whenever the user clicks on a program they haven't used recently. The user is accustomed to habitually typing in the admin password, so instant privileg
Re:This sword cuts both ways... (Score:5, Funny)
Please RTFA then resubmit with an accurate comment. Thank you for your attention to this matter.
Re:This sword cuts both ways... (Score:5, Informative)
Our production machines no longer allow access to the root account. This is quickly becoming the standard for prod machines.
Of course the problem comes when companies try to remove the ability to turn off protections. And then your IT staff spends time trying to work around or bypass arbitrary roadblocks.
Re: (Score:2)
"Neutering root is very useful on a business "production" system."
does not jive with your other comment.
"And then your IT staff spends time trying to work around or bypass arbitrary roadblocks."
Neutering Root itself has no value, because of administrative headaches. Less than 50% of IT professionals are passable at their jobs and only 20% good with practically 1% being excellent.
I have been on both sides, wishing for a way to reduce surface attack area, abstractions, and enhancing security in beneficial wa
Re: (Score:2)
Neutering Root itself has no value, because of administrative headaches.
I think you're wrong. Sudo you think you're wrong, too.
Re: (Score:2)
Neutering Root itself has no value, because of administrative headaches. Less than 50% of IT professionals are passable at their jobs and only 20% good with practically 1% being excellent.
Au contraire. I've developed set top boxes where we'd set the root password to a long random value and promptly forget what that password is. The box was flashed from firware and root wasn't necessary for the day to day operation of the device, or for maintenance, or updates and anyone trying to obtain was up to no good. I could easily see a "lock down" being a useful further security measure just in case they somehow did obtain root.
Re: (Score:3)
Sounds to me like you should have set the shell to /sbin/nologin or some such - that "forgotten" password is only forgotten until someone hacks it out of there.
Re: This sword cuts both ways... (Score:2)
> that "forgotten" password is only forgotten until someone hacks it out of there.
That's not how salted hashes work.
Sounds like only his init runs as uid 0 and the system is properly designed to work with reduced privileges.
Re: (Score:2)
I prefer /bin/false. There's no reason to give an attacker a message.
Re:This sword cuts both ways... (Score:5, Informative)
I need to be able to disable or remove these roadblocks entirely or they are useless
For typical Linux-on-server-or-desktop use, press the relevant keyboard sequence at your bootloader prompt, enter your bootloader password, and pass lockdown="".
Or, compile a new kernel without CONFIG_SECURITY_LOCKDOWN_LSM_EARLY.
If you can't do either of these, then you aren't the owner of the hardware, and if Linux didn't provide this feature, the vendor would have hacked something like this themselves anyway.
Re: (Score:2)
If you can't do either of these, then you aren't the owner of the hardware, and if Linux didn't provide this feature, the vendor would have hacked something like this themselves anyway.
That's kind of what worries me. I buy a lot of devices where I absolutely am the owner of the hardware because I bought it, but the manufacturer would sure like to dissuade me from that notion. The paranoid part in me sees this as being the potential start of Linux systems sold with a locked down kernel. With UEFI, it's not inconceivable they'd lock the bootloader down.
Re: (Score:2)
"Neutering root is very useful on a business "production" system."
does not jive with your other comment.
I think you meant "jibe".
"I speak Jive" (Score:3)
Re: (Score:2)
Cut me some slack, Jack! Chump don' want no help, chump don't *get* da help!
Re: (Score:1)
Neutering Root itself has no value, because of administrative headaches.
How is this any different than what OS X did from version 10.0.0, with disabling login for root, and later with System Integrity Protection?
Neither of those are particularly onerous to work with, if you know the username and password of an Admin User.
Re: This sword cuts both ways... (Score:2)
Containers and root (Score:2)
AWS containers typically let any process access root
Keep in mind that with modern containers technology, there is also namespaces for UIDs:
The "root" inside the container isn't actually "root", the Linux kernel has also ability to isolate that.
UID 0 inside the container is actually seen as some random high UID like 45687 from the outside, and thus gets no special privileges outside of the container.
You can give root access to some container access, and any wreck they manage to do will be limited to within the container only.
They won't be able to wreck the ho
Re: (Score:2)
"to be aware of spearfishing"
This is a user problem. If the user is root and runs arbitrary executables and death ensues, it is because that is what they intended to occur.
"or drive-by downloads"
This is an application problem. Usually a badly designed Web Browser. Especially one designed to execute arbitrary code from untrustworthy sources such as those "pushed" by Advertising companies (aka Chromium and its derivatives).
"Our production machines no longer allow access to the root account. This is quickly
Re: (Score:2)
Lock-down usefulness: Theory vs. Real world (Score:2)
Neutering root is very useful on a business "production" system. It's also useful for general staff in an office setting.
Yes, in theory, lock-down would be useful for security on servers or other very exposed machine (desktop that needs to constantly download suspicious shit from the internet).
The problem is that in the real world:
- Lock down isn't going to be used on the above machine, because the admins are going to be lazy and complain that "it gets in the way" in stead of finding a workflow that still works from them while using security.
- It's going to be used to the bone instead on personnal laptops and smartphone, beca
Re: (Score:2)
"Of course the problem comes when companies try to remove the ability to turn off protections. And then your IT staff spends time trying to work around or bypass arbitrary roadblocks."
Amen! Worked at a very large bank, who rolled out Avecto ... and totally hosed those of us running programs that required annual keys. *TRIED* very hard to work with the security department, but they were a bunch of process-quoting morons. The worst part of it is that Avecto themselves state that developers should have two
Re: (Score:1)
Policy quoting idiots are the worst. Might as well hire a parrot for the office.
Re: (Score:2)
Re: (Score:2)
For IT staff who are (in theory) trained professionals the ability is there to disable the option. This is needed when people, who know what they're doing, are trying to Get-Work-Done.
But when trying to Get Work Done, it is IT that inevitably steps in and says what you're doing is not approved.
Re: (Score:2)
Separation of concerns is good. I thought that was one of the reasons containers (docker/lxc) exist.
We have user namespaces for that. Why yet another mechanism, that seems more fragile and hard to configure properly?
Re: This sword cuts both ways... (Score:2)
Re: This sword cuts both ways... (Score:4, Interesting)
Yep, that is just 1 more problem with all of this "security" bullshit. There will come a time when every kernel will have a legal requirement for government to be allowed in, these things are just paving the way so that DRM and spying will be embedded at every possible stage of processing.
Most people fundamentally do not understand how many little black boxes are running under the hood of these systems.
Hopefully there will still be devs out there willing to fork away from this stupidity.
Re: (Score:2)
That ship sailed long ago (Score:3)
If you've never heard of Intels x86 System Management Mode then maybe don't go and find out about it unless you want to scare yourself.
Re: (Score:3)
There is, its called FreeBSD and its wonderful. Do you like an uncluttered system with good documentation? How about a conservative development cycle? With Linux if it compiles then it ships.
Re: (Score:3)
Re: (Score:2)
That's precisely why I like it.
Re: (Score:2)
Re: (Score:3)
Wow, paranoid much? It's just a new security feature. It's not even enabled by default. You can turn it on or off at your leisure. From what I've been reading Redhat has been running with similar patches in place for years.
Just chill out. Nobody is taking your opensource kernel away from you. Government can't mandate anything in something you have the source code for. When this patch rolls out in 5.4 your little linux system will still boot and run just as well as it did the day before.
Re: (Score:1)
I was wondering if Linux would be able to resist turning to the dark-side... I guess we now see even Linux will eventually become corrupt just like every OS. Vendors are definitely going to be trying to take as much advantage of this as they can.
You really don't understand the concept of Free and Open Source Software, do you?
Like the fact that it's entirely up to the system admin to turn this on or off, to harden their systems *if they wish* and that choice cannot be taken away by 'vendors', unlike with clo
Anti-systemd feature (Score:3, Funny)
Re: (Score:1)
Re: (Score:3)
It's a bit late to the party. Emacs has been the OS for decades before...
Re: (Score:2)
Yeah, but emacs was a good OS that lacked a good text editor.
Systemd is a shitty OS that lacks a good init system.
How is it locked down from being locked down? (Score:2)
This is much the same as putting a BIOS password in hardware/firmware on a PC. Once it exists, it MUST be used or at least protected. If you leave a laptop laying around with no BIOS password the first person who wants to can lock it down to themselves. If the facility for lockdown exists, it must be possible to lock malevolent players from activating it.
Once the 'lockdown' is built into the system, it's mandatory.
Re: (Score:1)
It's not, it never is.
The ONLY design intent is to remover user control and not anything else. No matter what BS they try to blow up everyone's skirts this is the only purpose behind it.
This fits right into the principal of "giving up liberty for a little temporary safety, makes you undeserving of either that liberty or safety".
There is a reason why everyone's phones are easily hacked and why everyone is easily spied upon.
Re: (Score:1)
kernel lockdown vs. kernel livepatch? (Score:4, Interesting)
Any interferences between the two?
BSD reference? (Score:3)
how about android networking ? (Score:2)
This is shipped in literally millions of devices... i.e. paranoid networking maybe time to get mainstream...
Linus Torvalds finally begins to ... (Score:2)
Re: (Score:1)
Microkernels look great on a whiteboard in a university lecture, but in the real world they absolutely suck. They're horrendously slow and complicated and that's why no mainstream OS uses them.
Re: (Score:3)
Re: (Score:2)
Yes, indeed. Microkernels are so simple they've never worked. Mach uses a hybrid microkernel, not a pure microkernel. I don't think there is a modern, working microkernel anywhere in the world that runs an entire operating system.
Re: (Score:2)
Re: (Score:2)
Are there any that come even _close_ to running a complete operating system? Network, graphics, and storage? HURD and Minix never managed it successfully enough to use.
Re: (Score:2)
Sounds like this will screw up some system utils (Score:2)
If even a root process can't create a raw socket (I assume thats what is meant by a raw port) then how will programs such as tcpdump and other network monitoring utils work? Also anything that needs to read or write raw ethernet frames is buggered. Also not everything can be found in /proc or /sys and sometimes accessing /dev/kmem can be useful.
Re: (Score:2)
If even a root process can't create a raw socket (I assume thats what is meant by a raw port)
It's not, it refers to raw access to physical (e.g. serial or parallel) ports (and not via TTY devices such as /dev/ttyS0), see e.g. https://linux.die.net/man/4/po... [die.net] or http://tldp.org/HOWTO/IO-Port-... [tldp.org]
sometimes accessing /dev/kmem can be useful.
Then boot with lockdown="" when you want to use it, but let's not let malicious code do that any time it wants.
Windows Did It (Score:2)
So Linux is finally reading the Windows security playbook from 15 years ago?
Re: (Score:2)
You mean the OS that had to have networking disabled to get a security rating fifteen years ago? Yeah, no.
Re: (Score:2)
More likely the Apple playbook from 5 years ago.
custom roms (Score:2)
i'm wondering how this will impact custom roms/images development.
not specifically talking about phones here, but just 'devices' in general.
in a lot of cases these were 'cracked' by a flaw somewhere, which then allowed full access and the ability to re-flash the OS with something the community has made, but is 10x better with regards to features, security and stability.
now imagine all such devices come with this feature enabled, that will make life a lot more difficult to truely open up these devices.
Linux is dead (Score:1)
SIP comes to Linux (Score:2)
Ahem, excuse me... "rootless."
Sandwiches (Score:4, Funny)
$ make me a sandwich
access denied
$ sudo make me a sandwich
access denied :(
Increasing complexity (Score:1)
Welcome to OpenBSD 2.6 (1999) (Score:2)
https://man.openbsd.org/secure... [openbsd.org] ...
So it took only 20 years for Linux to copy OpenBSD's securelevel(7)
nice