The Trusted Computing Base dates back to early Unix System V, having been seen on 3b2 Unix, as well as in SCO Xenix GT (I think) and SCO Unix; it's not by any means Openwall's idea.
And I've never really liked it, either... The more standard facilities you replace with your own BFIs, the fewer people have audited those implementations.
Openwall Linux 3.0: Linux for the security-conscious
Posted Jan 13, 2011 16:20 UTC (Thu) by solardiz (guest, #35993)
[Link]
The concept of trusted computing base is definitely very old. However, it is not limited to password "storage"/changing/authentication; that is just part of the TCB. Thus, our "tcb" package on Owl is sort of misnamed (it's just part of the TCB, not the entire thing), but it's named after the /etc/tcb directory also seen on some older Unix systems (sometimes called the "trusted" flavors by the vendors). I presume that you refer to the latter.
Now let's get to the real technical stuff: unlike those older systems, Owl and our "tcb" package is the very first implementation to make use of the shadow files separation to reduce the privileges of the "passwd" command. No other system did it before we did it in Owl. (Now our "tcb" implementation is also reused by ALT Linux's distributions and by Mandriva, which is great. I hope more distributions will follow.)
Yes, replacing standard facilities involves risk of introducing new vulnerabilities. However, with our "tcb", we're reducing privileges of used-to-be-SUID-root programs at the same time - so certain classes of potential vulnerabilities turn into almost non-issues for that reason.
I think that there are more people who have fully audited our "tcb" suite (that's at least its three developers, all of whom are "into security") than people who have audited, say, Linux-PAM (relevant since our "tcb" replaces Linux-PAM's pam_unix with its own pam_tcb). Ridiculously naive security holes in three Linux-PAM modules (upstream, not distribution-specific) were found last year: the modules were accessing users' files as root. These holes would not be in there if just one "security expert" had carefully audited the entire Linux-PAM tree before last year. (None of the affected modules were in use on Owl by default, which is why they had been excluded from our own mandatory audit... although we did build and package them, so we had to release a security update for those who might have made use of the modules. And guess who finally patched the holes in upstream's Linux-PAM? One of the "tcb" developers did.)
Openwall Linux 3.0: Linux for the security-conscious
Posted Jan 15, 2011 21:37 UTC (Sat) by gvy (guest, #11981)
[Link]
> our "tcb" implementation is also reused by ALT Linux's distributions
...as well as control(8) framework. Weird thing that a 4k shell library hadn't found its way into "mainstream" ditros to date.
Thanks!
Openwall Linux 3.0: Linux for the security-conscious
Posted Jan 16, 2011 19:11 UTC (Sun) by solardiz (guest, #35993)
[Link]
> ...as well as control(8) framework.
Yeah, quite some stuff from Owl is also in ALT Linux's distributions, and vice versa (patches to third-party software, enhancements to "Owl things" that we got back from ALT Linux). It's a good example of Open Source working right.
> Weird thing that a 4k shell library hadn't found its way into "mainstream" ditros to date.
Frankly, I didn't think it would ever get into any other distribution - which is why I called it owl-control initially (with the "owl-" prefix, which you can also see on Owl-specific components such as owl-etc, owl-hier, owl-startup, and more). I actually under-estimated Open Source: owl-control (renamed) also got into ALT Linux's distributions, and it's been ported to FreeBSD by Matthias Schmidt (I'm afraid that very few people are aware of this, though...) Maybe we should make owl-control available separately from the Owl source tree as well (like we do for several other components from Owl, including "tcb"), which will make more people aware of it. Maybe "owl-control for export" should get its own name - suggestions are welcome.
Similarly, maybe we should start exporting our ports-from-OpenBSD for reuse on other Linux systems/distros (and maybe even non-Linux) - I'd start with mtree(8), which few non-BSD folks are aware of.