Commit on missing "privilege" Note

Came across an omission when testing LBA support for 386BSD (shush - that's for later, as 386bsd only supported CHS). There was a missing privledge, easily added in.

Literally there are thousands of things that happen when you do an system release. Everytime you'd do a release (I did them for Berkeley on the PDP 11, for National Semiconductor on the NS16032, a vareity of start-ups, and ... 386bsd of course). You'd get used to a stream of emails with "add this in here, it does this". They'd be concious of the fact that you'd be overloaded, so they'd carefully think about the omission, how to word it, ... because they'd be afraid. That it wouldn't make it into the next release because it was too obtuse (or wrong) or time consuming, so it would be skipped. I never knew how valuable this was, and took it for granted.

One of the surprises with 386BSD was that the volume of such "input" was exponentially more (not that surprising) as well as "not" carefully thought. They'd decided it was "customer support", not assisting a research project (carefully labeled such from the start, to avoid this confusion). And with the magazine CDROM, by contract support and rerelease of any follow-ons were the responsibility of the publisher. (We'd done a product (Symmetric S/375 Symmetrix) with $1K/unit bundled support contracts, so we knew this from the start.) We were just involved with improving the research on 386BSD. All of this didn't matter.

Role based security and 386BSD was mentioned in our Dr Dobbs article Network security at the operating-system levela, and later in Chapter 7 of The Basic Kernel book, Source Code Secrets series.

Most didn't bother to read anything, where the main point of 386BSD being a "living example" was dead to them. That's why the article series, talks, and books were being generated. So they would be read and used.

Apparently that wasn't understood.

So the only reference I could find to this "bug" had the guy ripping out the role based security, instead of the teeny, tiny commit that you see it needed.

The "why" behind role based security is another story entirely.

It came out of my consulting on operating systems security. I had done the architecture for B1 labelled security for government systems, including those by Hewlett Packard. These systems had huge bit vectors of discrete privilege "bits", that were unweildy to manage.

In the "Orange" and "Green" books (government NCSC) they suggested these might be "compressed" into "roles". And that these roles might be assigned to secure paths of access. As independent to cryptography/secrets/passwords/credentials. Some of us thought that any code could be broken (or subverted). But if you structured things around access path, your could reduce exposure.

Post 0.1 386BSD releases were under a barrage of criticism. That certain research work wasn't but someone elses ideas. So suddenly much that wasn't on the development agenda suddenly needed to be justified.

The most simplified version of role based security was added in, and we expected we'd miss much. From the book:

In other words, it was a demonstration of the concept with the direct benefit of reducing the scope of even compromising root over any network. Not the end by any means, but an illustration of a beginning.

This allows for an intermediate gateway to interpose for access (like the way a fileserver functions), an RPC tracer, an insertion of an audit log, and a back call framework into the user space library to allow a security library to take action on potential intrusion.

So, a stub that other things could attach to.

Since this was written, several million intrusions into BSD systems, including OpenBSD, have occured that was the point of this stub and framework. How far should this be continued is something I'm considering.

Perhaps a reason for reading articles, books, and alternative approaches. Or even ... notebook entries? Take care.