LSARC/2008/061 - Indiana check list

[James Carlson]

Alan Coopersmith writes:
> James Carlson wrote:
> > I'm a little confused about the relationship between this checklist
> > and Indiana. 
> 
> Unfortunately, we've overloaded "Project Indiana" - this part isn't about
> building a new distro, but about the related effort to add a whole lot of
> external open source to Solaris/OpenSolaris, to provide a more useful set
> of software out of the box, whether you're getting the packages from the
> Nevada CD's or the Indiana online package repository.

Ah ... I see.  Still, I'm confused about whether _any_ external open
source project can make use of this checklist, or only a special set
that are part of this looser confederation of projects?

What if Joerg comes to us tomorrow and asks to use this checklist to
gain automatic approval for one of his projects?  Does that work?
(Not to pick on him particularly, but he came to mind.  ;-})

More generally, can it work for any external source?  What about
purchased software?  Provided that there's an upstream, and that we
have less direct influence over that upstream[1], why do we care
enough about the upstream development model and/or legal foundation to
write special rules for things inbound from an "open" location versus
things inbound from a "closed" one?  How is that an architectural
matter?

I'm not completely positive on this (as I'm still not sure about the
underlying purpose of this checklist), but it seems that we're being
asked to carve out a hole.  If that's so, then I'd like to know
approximately where the hole will be sited, and some idea of the size.

> >>       If yes then are the setuid/setgid privileges handled by the use of roles?
> >>       [ ] Yes
> >>       [ ] No - ARC review required
> > 
> > I might be missing something here, but since RBAC is currently a
> > Solaris-only facility, doesn't this at least imply that we're either
> > forcing changes upstream or forking?
> 
> Isn't this just taking the upstream binary, and instead of installing it
> setuid/setgid adding an entry to the RBAC configuration files to allow users
> with specific profiles to run it with added privileges?   That shouldn't
> require any source changes in many cases.   (It didn't for the X binaries
> I've had to do this with.)

It may ... depending on what privileges are involved and how they're
used.  For instance, it's possible to provide separate configuration
read and write privileges for individual administrative utilities, and
if the utility itself doesn't make those fine-grained checks, nothing
else will.

You're right that it might be "just" a packaging and delivery change.
But even there, I'm not sure that all packaging changes are
necessarily no-ops from a maintenance perspective.


[1]  I still don't see how influence comes into the picture here.  It
     seems to be part of the fundamental assumptions of this proposal
     that having direct influence on the project design is necessary
     in order to have proper system architecture, and that we
     otherwise must just swallow what we're given.  If it's external,
     we slap it together and hope for the best.  It's never been that
     way before, and there seems no necessary reason to suppose it
     should be now, so I can't quite figure that out.

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677