Sudo (and other setuid programs) could in principle use privilege separation to punt everything not absolutely essential to an unprivileged context and thereby reduce the size of the TCB.
(And this isn't even the most arcane part of linux userland authorization and authentication. PAM is by far the scariest bit, very few people understand it and the underlying architecture is kinda insane)
It literally replays in the terminal like a movie. It's nice, but I worry too much about the security implications (passwords captured, etc) to roll it out.
edit:
Ah yes, sudoreplay. You can see this video a playback via it. That's not the guy typing, that's sudoreplay time-accurately replaying what happens.
script --log-timing file.tm --log-out script.out
# do something in a terminal session ...
scriptreplay --log-timing file.tm --log-out script.out
# replay it, possibly pausing and increasing/decreasing playback speedAccounts thereafter, ruined everything.
One we started using connected machines for much and people with flexible though morals noticed that there was trust in the system(s) ripe for exploitation for fun or profit or both.
I remember SMTP hosts being open by default because it wasn't a problem, that very quickly changed once spam was noted as potentially profitable.
There were accounts all over from quite early on, in academic environments before businesses took much of an interest, if only to protect user A from user B's cockups ("rm -rf /home /me/tmp") though to some extent also because compute time was sometimes a billable item, just not on single user designed OSs¹.
[1] Windows, for example, pre NT & 95 (any multi-user features you might have perceived in WfW 3.x were bolted on haphazardly and quite broken WRT actual security)
More precisely, it runs as the file owner. Which is often root.
I didn’t exactly know what setuid did. I learned something today. :)
Going off its security advisories page [1] and this tracker [2], it seems to be around 43 CVEs, most rated high severity.
So the actual rate would be 43 CVE / 430 kLoC = ~0.01 CVE per kLoC, so ~2.65 CVEs for udisks and ~0.2 for pmount.
[0] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=sudo
cpe:2.3:a:sudo_project:sudo:*:*:*:*:*:*:*:*
cpe:2.3:a:todd_miller:sudo:*:*:*:*:*:*:*:*
Those CPE IDs were determined by a brute-force-ish XML grep:
xml select -N cpe-23="http://scap.nist.gov/schema/cpe-extension/2.3" -t --match '//cpe-23:cpe23-item' --if 'contains(@name,":sudo:")' -v "@name" -n official-cpe-dictionary_v2.3.xml
This web service is free: https://cve.circl.lu/ But, you cannot search directly by CPE right now; you can start a search by vendor, then filter by product:
todd_miller sudo: 58 vulnerabilities
sudo_project sudo: 42 vulnerabilities
Repo here: https://github.com/trifectatechfoundation/sudo-rs
It's permissively licensed, unfortunately. Wonder why. It's not a library. But it ought to improve security in the long run.
I've been loosely involved in setting this up, so I can say a little: The people that funded the initial work wanted it permissively licensed. My (somethwat informed) conjecture is that they rank making things secure - even in closed source apps that now could take the code - higher than barring closed forks. It also tracks with the Rust ecosystem in general - APL or derivates are very common in that ecosystem.
What makes you say that? I'm not trying to be argumentative, I'm genuinely interested.
At times the authors who rewrite-in-foo are just motivated to expand the foo ecosystem and are not primarily interested in making a working program, much less in possession of the requisite subject matter expertise or focus.
On the other hand, if the replacement isn’t targeting full sudo feature set and also reducing the amount of code and/or making architectural improvements like keeping most code not running as root, then the blast area of such logic bugs can be reduced.
* https://github.com/trifectatechfoundation/sudo-rs?tab=readme...
Well that makes it useless for $WORK (for now), as we use LDAP as our central policy repo (and more generally our user account store). Will have to wait until (at least) that's implemented before we can even consider it.
> It's permissively licensed, unfortunately. Wonder why.
So it can be used distributed with fewer legal hassles.
[0] - https://www.freedesktop.org/software/systemd/man/devel/run0....
Well damn that's a shame. I just hate it when people let others use their work in a way they choose, that happens to be less restrictive than my own personal choices.
/s of course.
Copyleft licenses are demonstrably better for open source projects in the long run. We've had enough time to prove that out now.
Look beyond the OS, and much of the tech stack is dominated by non-copyleft open source projects. Both the major web servers--Apache and nginx--are permissively licensed, for example. Your SSL stacks are largely permissively licensed; indeed, most protocol servers seem to me to largely be permissively licensed rather than copyleft.
And I should also point out a clear example where copyleft has hobbled an ecosystem: Clang and LLVM have ignited a major compiler-based ecosystem of ancillary tools for development such as language servers. The gcc response to this is... to basically do nothing, because tight integration of the compiler into other components might allow workarounds that release the precious goodness of gcc to proprietary software, and Stallman has resisted letting emacs join in this revolution because he doesn't want a dependency on non-copyleft software. An extra cruel irony is that Clang appears to be an existential threat to the proprietary EDG compiler toolchain, which would mean it took a permissive license to do what the goal of the copyleft license was in the first place: kill proprietary software.
To the contrary, GNU Hurd is GPL'ed and is much less successful than the linux kernel.
In the end, if you want projects to succeed they need contributors. Unfortunately, some of them need to be reminded to play fair more than others, and in those cases the legalese helps.
You clearly didn't understand my point: I'm not arguing about whether GPL is better than MIT or BSD or even SSPL/etc.
My point is that if someone else chooses to release their software with less restrictions on it than I would choose, that's literally none of my business.
They wrote the fucking thing, they get to choose how it's fucking licensed.
Plenty of organisations (and thus people) skip using GPL licensed software due to inability or unwillingness to be bound by it's terms.
I'm still waiting for the day the GPL camp says they're not going to use things like OpenSSH, Apache, Nginx, Postgres, Python, Ruby - because they're too fucking permissive.
sudo, another setuid binary with a lot of policy code, has 210 CVEs / 430.150 kLoC = ~0.5 CVE per kLoC.
57.5% of CVEs have a CVSS >= 7, so 0.5 * 0.575 = 0.2875 CVE7/kLoC.
As a back-of-envelope estimate,