James Carlson wrote: > What we're asking here is how the delivered features themselves are > properly integrated with the rest of the existing Solaris features, > notably Least Privilege and RBAC. If the answer is that they're just > not integrated because that's ETOOHARD (which is what I *think* you're > asserting), then perhaps architectural review is itself too hard. > No, I'm not asserting ETOOHARD. I'm claiming that there needs to be a balance between architecturally correct and end-user useful.
> The safest and simplest thing by far to do would be to deliver them > with no RBAC profile at all -- that is, simply fail to integrate with > Solaris, and force the user to figure it out. That way, you wouldn't > be accidentally granting access to harmful things (things that can > cause privilege escalation) through an existing profile. > > That'd work, but the result over time of many projects doing this is > that Solaris itself becomes incomplete: more and more things skip > RBAC, omit auditing, and opt for init.d scripts rather than SMF. > Eventually, we wind up with a trash pile of incomplete features. > Yes- this point is very well taken. > I guess I don't know whether we care about that. I would suggest that > Darren and Gary do, which is why they spoke up. It's not to slow down > a project or make it "geologic," but to find out what makes it complete. > Yes. The "geologic" observation on my part is that so far is that some issues have become so hard that to all intents and purposes change comes on the order of decades. That isn't to say that changes don't come and when the come they aren't valuable when complete- but the balance above isn't necessarily consciously struck. Perhaps what needs to happen here is the putative usefulness of the package not only in and of itself but as part of the overall "let's look friendly to people who use linux" needs to be balanced with: + Is it worth including at all? + Is it worth including even incomplete wrt RBAC? + Is it worth including if it takes a year to sort out RBAC and other issues? If these questions are answered by the submitters with some business case, then the architectural issues can be weighed properly. Secondarily should be the recognition that useful tools get put onto Solaris installations whether approved by Sun or not. If sg3_utils has a solaris piece already (haven't checked recently), people will just add it anyway. Perhaps another thing to make the inclusion of these packages easier is a "optional but unsupported because...." category which is just a documentation exercise. Like, we could say "sg3_utils is something you can add, but it doesn't meet the Solaris criteria of a, b, c which is why it's not part of the default release. You have been warned". > > >> I'm playing dumb user in this paragraph. If I, as a user of OpenSolaris >> (which seems to be tuned towards user/developers, not restricted >> users), plug in a device to my machine, I expect reasonable permissions >> *or* automated to tools to use that device. Therefore, whatever >> permissions framework allows me to use this package of tools seems >> reasonable to expect.<br> >> > > We're talking about privileges granted to a process, not how > permissions on a device are set. They're different issues. > > Oh, yes, sorry. My bad.
