A local root vulnerability in glibc [LWN.net]

A local root vulnerability in glibc

Posted Oct 5, 2023 6:12 UTC (Thu) by joib (subscriber, #8541)
In reply to: A local root vulnerability in glibc by bluca
Parent article: A local root vulnerability in glibc

I'm not an expert, but from reading on the topic over the years my rough conclusion is that if we started to design an OS from a clean sheet today we'd start with a capability based security design (well, might even apply to hardware level protections via things like CHERI etc. instead of traditional virtual memory based isolation). And in such a design, crucially, you can only drop capabilities, not gain additional ones. So in a way, when the system boots, the OS kernel has some kind of root capability, from which it can dole out subsets to other parts of the kernel, user space processes etc. In order to (temporarily) get more capabilities, as increasing capabilities is verboten, one would need to acquire a higher capability context via some form of authentication.

Of course, in reality zillions of $$$ are invested in current OS'es and applications that run on them, and a clean sheet design is but a dream. So the problem becomes how to somehow approximate that without massively breaking the existing system. And yes, "yeeting suid/fcaps into the sun" is probably a big part of it. As for how to temporarily get the higher capabilities, yes some form of IPC might be the practical solution. Or ssh to a local socket or such. And the NNP flag for tasks could probably help as well. Come to think of it, that would also allow jettisoning all this ruid/euid/suid stuff as superfluous.

to post comments

A local root vulnerability in glibc

Posted Oct 5, 2023 7:52 UTC (Thu) by nim-nim (subscriber, #34454) [Link] (1 responses)

You start with the ideal security mantra 'only drop capabilities', then you realise you need most of those capabilities at one time or another for a long running system (as opposed to a toy that boots 2h in a lab), then either you admit your original goal is flawed or you ask via IPC something that was not foolish enough to drop caps to do whatever is needed.

So basically your billions of billions of software rewrite only move you from "you need to fool something able to elevate privileges to do evil" to "you need to fool something that runs permanently with elevated privileges to do evil". And you get a nice fat IPC channel that does not exist in the first scenario to accomplish this.

Of course in the first prototypes the IPC channel is small and easy to control, once you’ve shoved all the use cases that require privilege escalation today inside who actually thinks it will stay small and easy to control?

A local root vulnerability in glibc

Posted Oct 5, 2023 7:56 UTC (Thu) by nim-nim (subscriber, #34454) [Link]

Not that privilege separation is bad, it is very nice when done properly (see postfix), but it is awfully hard to do properly at scale for a whole system, because that requires deep thought on where each privilege is actually needed.

A local root vulnerability in glibc

Posted Oct 5, 2023 22:46 UTC (Thu) by shemminger (subscriber, #5739) [Link] (8 responses)

Intel tried building an OS with capabilities and HW support back in the 1990's.
In addition to biting off to big a task, what did run was incredibly slow an never made it out to the public. They invested lots of money at the time.

A local root vulnerability in glibc

Posted Oct 6, 2023 8:39 UTC (Fri) by geert (subscriber, #98403) [Link] (2 responses)

Which does not mean it is not feasible now, only that it was not feasible in the nineties.

During development, Intel simulated the 80386 at the gate level on an IBM mainframe, which was rumoured to take one week to boot DOS. Nowadays we boot simulated Linux-on-LiteX-VexRiscv using Verilator on our desktops in minutes.

A local root vulnerability in glibc

Posted Oct 6, 2023 14:46 UTC (Fri) by Wol (subscriber, #4433) [Link] (1 responses)

> simulated the 80386 at the gate level on an IBM mainframe, which was rumoured to take one week to boot DOS.

Bear in mind the architecture differences between a micro-processor and a mainframe. Mainframe CPUs were (maybe still are) slow even by their contemporary standards. The whole point of a mainframe is that the machine is mostly co-processors, which do most of the work.

I remember the days when they attempted to port Pr1mos to Intel - so the story goes it was a disaster. The 50-series CPU relied on the segmented virtual memory architecture, and the 80386 (I think that was the chip) was hopeless.

So no, I don't believe it wasn't feasible in the 90s. It was just that the x86 architecture was sweeping everything else away (thanks to the IBM PC), and all the awful design decisions that went into it effectively hindered and hamstrung a lot of far more superior work. As usual, "cheap but crap" won the battle, but cost us the dear.

Cheers,
Wol

A local root vulnerability in glibc

Posted Oct 6, 2023 17:11 UTC (Fri) by mpr22 (subscriber, #60784) [Link]

IBM have, in recent years, been more than happy to boast that their mainframe CPU cores, of themselves, are the fastest microprocessors in the business :)

Intel iAPX432

Posted Oct 8, 2023 8:05 UTC (Sun) by CChittleborough (subscriber, #60775) [Link] (4 responses)

If you mean the Intel iAPX432, it was created in the 1980s. It was a fairly vertical microprogram with enormous amounts (for the day) of microcode on chip. That microcode provided an ISA which was a superset of what Ada needed: a multitasking operating system with capabilities and concurrent garbage collection in Silicon. One of the superset features was that a called procedure could survive returning to the caller, like call/cc in Lisp. To do this, the microcode had to allocate the frame for each called procedure on the stack. When they got it running, they found that it could do 50 procedure calls per second: a bare procedure call took an average of 20 ms.

Wikipedia has a relatively decent article on this, though it leaves out the 50 calls/sec bit (which I heard in a talk by Prof Ed Gehringer).

Intel iAPX432

Posted Oct 8, 2023 8:07 UTC (Sun) by CChittleborough (subscriber, #60775) [Link]

Err, the point I meant to make is that I do not think the capability addressing was the main problem with the 432.

Intel iAPX432

Posted Oct 8, 2023 14:03 UTC (Sun) by jem (subscriber, #24231) [Link] (1 responses)

To be precise, the project was started in 1976, and the product was launched in 1981. Meanwhile, to defend against competitors like Motorola and Zilog, Intel introduced the 8086 as a stopgap solution. We all know what happened after that.

From the Wikipedia article: "The iAPX 432 instructions have variable length, between 6 and 321 bits." Maybe partially as a reaction to this madness, something else was emerging from Berkeley: RISC. Roughly at the same time, in popular music, psychedelic progressive rock was replaced by punk rock.

Intel iAPX432

Posted Oct 9, 2023 2:17 UTC (Mon) by CChittleborough (subscriber, #60775) [Link]

Thanks for correcting me about the dates. Thanks also for the memorable, amusing and insightful analogy between RISC and punk rock!

Intel iAPX432

Posted Oct 9, 2023 9:02 UTC (Mon) by james (guest, #1325) [Link]

There is a fascinating oral history interview with Bob Colwell, senior architect on the Pentium Pro and the Pentium 4. He says (PDF, sorry) that in 1984:

...we went up to this bar where I struck up a conversation with some random guy I didn't know sitting next to me. He asked me what I was doing at Intel for the summer. I said "I'm a grad student doing some research on the 432." "Really? What kinds of things are you finding?" I said "Well, I'm finding that there's a huge disconnect between the software and the hardware. I mean the hardware should be capable of doing a procedure call much quicker than it's actually doing, for instance, it's taking many hundreds of clock cycles. And in other places, I'm seeing all kind of wastage from the compiler just setting variables that never get used, classic stuff you just don't do." And the guy said "Really? I mean tell me more about that part."
Eventually, I said "Okay, who are you? You know way too much about this technology." He tells me "I'm the leader of the compiler team." And I said "In that case I probably just fatally offended you." He said "No, not at all because I know we generate bad code and I don't care." He said "We don't like the 432 hardware team." And I thought "Oh my God, there is no hope that this project is going to work when you have the two main casts killing each other." He said "That hardware team never listened to us compiler folks At some point we decided that we'd live up to the letter of the contract but beyond that? No."

and

Well somewhere along the way, they threw away a little bit too much performance, and if they had been paying attention to that aspect of it, I think that they could have fixed those pieces, and if they made peace with the compiler guys they could have fixed that part of it too. They could have actually got within shouting distance of a competitive part. But, as it was, there were so many mistakes that there was no way to recover from them all.

It's a fascinating read.

A local root vulnerability in glibc

Posted Nov 18, 2023 1:48 UTC (Sat) by Rudd-O (guest, #61155) [Link]

Genode does exactly this. And it can run Linux in a VM. All drivers are in user space and none have more privileges than the absolutely required.

Genode is truly cool. Give it a spin.