sudo [PSARC/2008/370 FastTrack timeout 06/17/2008]

[James Carlson]

Darren J Moffat writes:
> James Carlson wrote:
> > Darren J Moffat writes:
> >> I also don't see how any of this is relevant to ARC review.  The TOE is 
> >> not reviewed by ARC and not produced by ARC.
> > 
> > The interesting thing for this case, though, is that we're apparently
> > making decisions about what architectural features are necessary based
> > on whether something will ultimately show up in the TOE.  
> 
> I don't think we (at least not the Solaris security group we) are, 
> because if we were this case wouldn't exist because adding sudo isn't 
> necessary for Common Criteria evaluation.  sudo is necessary for 

Suppose (besides being "necessary") we decided we *wanted* to include
sudo in the TOE.  Would this project proposal look any different?

If yes, then doesn't that mean that there's an architectural issue
here with respect to the things that are deemed to be "necessary" for
the TOE and those that are not?

> Yes there is an issue with all this upstream FOSS that is being added to 
> Solaris and what the impact on the evaluation target for Common Criteria 
> is. However that issue already exists regardless of any upstream FOSS 
> just based on new code added to Solaris.  For example zones had a big 
> impact on evaluations, so does the crypto framework.

Sure; agreed.

> I'm really sorry I suggest the project team mention this in the case 
> materials because otherwise I think this case would have just sailed 
> through.

No need to be sorry.  I'm asking questions so that I understand the
boundaries and implications of the case.

There are decisions being made here that appear to affect the way in
which we integrate certain bits of software, and that are possibly
architectural in nature, but that are not being expressed as
architectural rules.  That seems at least a bit confusing to me.

>  > If it's
> > there, then it needs careful scrutiny for auditing and the like.  If
> > it's not, then that no longer applies.
> 
> Generation of audit records is mostly done by the kernel, sudo is purely 
> a userland application.  As I said in my other email it isn't that sudo 
> will stop audit records it just won't add any new ones like pfexec does. 

Right ... and wouldn't we include that additional auditing
information, just like pfexec, if we were considering sudo for
evaluation?  In fact, wouldn't we _insist_ on it?

>   I don't see an issue with that for the first integration and it is why 
> the case says we will work with the upstream community to consider 
> adding more auditing.

I'm not asking any such thing.  I don't want auditing in sudo.  I
don't care whether it has it or not.

I'm asking to understand the principle behind the decision being made,
as it likely affects future cases.

-- 
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