“In hindsight it seems reasonable, but I had no idea there was a filesystem bit that marked a program to be run as it’s owner. It’s a really cool mechanism!”
From a security standpoint, setuidroot bit was a bad idea: hackers went straight for those programs trying to get malicious code in via either the filesystem or the running program.
TIS solved the filesystem part in Trusted Xenix: a B2-class UNIX designed for privilege reduction among other things. The OS automatically cleared the setuid bit any time an executable file was written to. The administrator had to manually reset the bit. The thought was that the only legitimate writes would be updates by administrator. The other UNIX’s required people to constantly watch out for these kinds of programs. It took time before they got the problem under control.
I’m running Gentoo and I’m surprised sudo still has a setuid bit. I know a lot of other programs on Gentoo use filecap extended attributes instead (like for example, ping and ping6, which use to need a setuid bit).
The chk_passwd command for the pam module is also another thing that uses filecaps (if you use an old Gentoo image, possible an Arch image too, and rsync it to a machine without copying extended attributes, there a good chance screen unlocking and ping won’t work).
Are filecaps not powerful enough to work for the sudo binary?
IIRC (been a while now for me) but isn’t setuid programs something you need to look for with PCI compliance for that very reason? I vaguely recall having to account/audit for all setuid programs and justify their having setuid. That said solaris didn’t behave too well changing some of those programs setuid bits so we always got dinged for things we couldn’t change.
After using openbsd’s doas, I have to say its miles less of a pain than sudo setup is. Not seen TIS though thanks for the link! Is it far off from solaris acls/rbac? (I’ve not yet read the link so exuse the possibly stupid question)
While setting up trusted solaris stuff could be a pain, it was rather nice compared to most of the stuff I’ve seen in linux land.
I can’t recall if it’s in PCI compliance but account/audit for all of them was standard practice. That is, standard practice avoided with a better design like in Trusted Xenix. The TCSEC was the first standard for security certification that mandated specific features and assurance activities in systems including mandatory access controls (not bypassable by users), least privilege, and plugging leaks. This work is an easy description of the security kernel concept with two exemplar OS’s whose designs were certified as high assurance (B3 or A1). The B1-B2 systems only use some features or techniques of B3/A1 systems like mandatory access control. Less-rigorous design/implementation means more vulnerabilities, though. The tradeoff is made to have more features, lower cost, backward compatibility, and other usual reasons for less security. Trusted Xenix (1990) was maybe the third secure UNIX but the first deployed in the commercial sector vs an academic prototype.
Interestingly, I think OpenBSD was started either the last year or just after of Trusted Xenix. I think it ended in 1994 when NSA was sabotaging the TCSEC on top of market not willing to sacrifice features or higher pricing for better security. Regarding doas, though, what did you find about it that was easier than sudo? I’m on Linux so curious.
Interesting info on Xenix, bit before my time in Unix land. I think I started on around sunos 2.5.1 so might have missed all that jazz. I need to have a refresher where solaris rbac fits into all that work, I vaguely recall it being based off of some government work at the time. But my memory is crap and its not too big of a deal where it fits in.
As for doas, the config format is blindingly simple compared to sudoers, I was never a huge fan of sudoers config format. Excerpt from my firewall setup:
General format is permit|deny [nopass] user cmd /full/path/to/executable args allowed args.
Reminds me more of firewall white/black lists to be honest compared to the sudoers setup. I can NEVER remember how to setup sudoers with the nopassword option, doas its beyond easy to recall as I don’t need to worry about any host alias stuff or whatnot.
Essentially, its just way more KISS compared to sudo, which leads me to think its probably more secure in general as there is a lot less parsing to get wrong.
Since I dont use Solaris, I couldnt be more helpful in comparison. Key difference is MAC vs discretionary models like users, groups, and roles. MAC is strict. Trusted Solaris was the one with that stuff. SELinux does same thing but with different model (type enforcement).
Thanks for description of doas. Gives me the idea that making the language for stuff like it match firewall language might help beginners learn faster. Could also try to use an access/authorization language for most or all such things for consistency. Many exist.
It basically worked like a separate user you could switch to to do certain work. Was a bit of a pain to setup but once there it was pretty easy to use.
I never thought about the impact of the config language as to simplicity for beginners. But not having to try to expand out aliases/variables does make parsing the config file by eye way easier.
I know the later versions of these kinds of products often had RBAC due to market demand. Trusted Xenix may have been too early for it. XTS-500 had it. That was STOP’s successor.
That could be, rbac/solaris were a while back for me now so I can’t recall if AIX or HP/UX had their own RBAC implementations.
In either case the irony for RBAC/solaris was that most places I did stuff at moved away from RBAC to sudo as most people never remembered to su - rolethatletthemdostuff instead of sudo do stuff.
“In hindsight it seems reasonable, but I had no idea there was a filesystem bit that marked a program to be run as it’s owner. It’s a really cool mechanism!”
From a security standpoint, setuidroot bit was a bad idea: hackers went straight for those programs trying to get malicious code in via either the filesystem or the running program.
TIS solved the filesystem part in Trusted Xenix: a B2-class UNIX designed for privilege reduction among other things. The OS automatically cleared the setuid bit any time an executable file was written to. The administrator had to manually reset the bit. The thought was that the only legitimate writes would be updates by administrator. The other UNIX’s required people to constantly watch out for these kinds of programs. It took time before they got the problem under control.
I’m running Gentoo and I’m surprised sudo still has a setuid bit. I know a lot of other programs on Gentoo use filecap extended attributes instead (like for example, ping and ping6, which use to need a setuid bit).
The chk_passwd command for the pam module is also another thing that uses filecaps (if you use an old Gentoo image, possible an Arch image too, and rsync it to a machine without copying extended attributes, there a good chance screen unlocking and ping won’t work).
Are filecaps not powerful enough to work for the sudo binary?
IIRC (been a while now for me) but isn’t setuid programs something you need to look for with PCI compliance for that very reason? I vaguely recall having to account/audit for all setuid programs and justify their having setuid. That said solaris didn’t behave too well changing some of those programs setuid bits so we always got dinged for things we couldn’t change.
After using openbsd’s doas, I have to say its miles less of a pain than sudo setup is. Not seen TIS though thanks for the link! Is it far off from solaris acls/rbac? (I’ve not yet read the link so exuse the possibly stupid question)
While setting up trusted solaris stuff could be a pain, it was rather nice compared to most of the stuff I’ve seen in linux land.
I can’t recall if it’s in PCI compliance but account/audit for all of them was standard practice. That is, standard practice avoided with a better design like in Trusted Xenix. The TCSEC was the first standard for security certification that mandated specific features and assurance activities in systems including mandatory access controls (not bypassable by users), least privilege, and plugging leaks. This work is an easy description of the security kernel concept with two exemplar OS’s whose designs were certified as high assurance (B3 or A1). The B1-B2 systems only use some features or techniques of B3/A1 systems like mandatory access control. Less-rigorous design/implementation means more vulnerabilities, though. The tradeoff is made to have more features, lower cost, backward compatibility, and other usual reasons for less security. Trusted Xenix (1990) was maybe the third secure UNIX but the first deployed in the commercial sector vs an academic prototype.
Interestingly, I think OpenBSD was started either the last year or just after of Trusted Xenix. I think it ended in 1994 when NSA was sabotaging the TCSEC on top of market not willing to sacrifice features or higher pricing for better security. Regarding doas, though, what did you find about it that was easier than sudo? I’m on Linux so curious.
Interesting info on Xenix, bit before my time in Unix land. I think I started on around sunos 2.5.1 so might have missed all that jazz. I need to have a refresher where solaris rbac fits into all that work, I vaguely recall it being based off of some government work at the time. But my memory is crap and its not too big of a deal where it fits in.
As for doas, the config format is blindingly simple compared to sudoers, I was never a huge fan of sudoers config format. Excerpt from my firewall setup:
General format is permit|deny [nopass] user cmd /full/path/to/executable args allowed args.
Reminds me more of firewall white/black lists to be honest compared to the sudoers setup. I can NEVER remember how to setup sudoers with the nopassword option, doas its beyond easy to recall as I don’t need to worry about any host alias stuff or whatnot.
Essentially, its just way more KISS compared to sudo, which leads me to think its probably more secure in general as there is a lot less parsing to get wrong.
env setup looks simple too but i’ve not yet needed that for any of my needs: https://man.openbsd.org/doas.conf
Since I dont use Solaris, I couldnt be more helpful in comparison. Key difference is MAC vs discretionary models like users, groups, and roles. MAC is strict. Trusted Solaris was the one with that stuff. SELinux does same thing but with different model (type enforcement).
Thanks for description of doas. Gives me the idea that making the language for stuff like it match firewall language might help beginners learn faster. Could also try to use an access/authorization language for most or all such things for consistency. Many exist.
No worries, from a quick glance rbac does appear to be related to the mac setups you’ve linked to.
A quick overview of how roles/rbac work(ed) on solaris: http://www.oracle.com/technetwork/systems/security/custom-roles-rbac-jsp-140865.html
It basically worked like a separate user you could switch to to do certain work. Was a bit of a pain to setup but once there it was pretty easy to use.
I never thought about the impact of the config language as to simplicity for beginners. But not having to try to expand out aliases/variables does make parsing the config file by eye way easier.
I know the later versions of these kinds of products often had RBAC due to market demand. Trusted Xenix may have been too early for it. XTS-500 had it. That was STOP’s successor.
That could be, rbac/solaris were a while back for me now so I can’t recall if AIX or HP/UX had their own RBAC implementations.
In either case the irony for RBAC/solaris was that most places I did stuff at moved away from RBAC to sudo as most people never remembered to su - rolethatletthemdostuff instead of sudo do stuff.