[Security_sig] Re: [dcl_tech_board] Some notes from the CGL security discussion

Lynn de la Torre ldelatorre at osdl.org
Mon Aug 9 13:23:23 PDT 2004

It looks like you did a good job of transcribing the requirements as
they were expressed on the conference call.

Thanks for doing this.

On Wed, 2004-08-04 at 16:59, Gé Weijers wrote:
> Hello,
> Here's what I picked up from the DCL security assumption discussion of 
> last week:
> 1) We will limit ourselves to application and database servers for now. 
> The edge is a more complicated issue.
> 2) In current practice administrators have full access to the system 
> (classical root access). How much we want to buck that trend remains to 
> be determined.
> 3) The following features are needed:
> - Privilege Separation, the splitting up of all-or-nothing root 
> privileges into individual privileges that can be assigned separately. 
> This helps privilege minimization.
> - Roles, which allow the (temporary) assignment of privileges to users.
> - Installation and especially configuration of software without 
> requiring root privileges
> - Immediate revocation of privileges
> 4) Developers have shell access to systems, and therefor shell access is 
> much more of an issue than for CGL. DCL needs some resistance against 
> mistakes. We do not assume though that users are malicious or very 
> sophisticated technically.
> 5) A question for the troops: do clustered systems require anything 
> special security-wise (e.g. a separate network for cluster messages).
> 6) the security of the application/database server environments are 
> mostly determined by their environment. Good administration practice of 
> disabling unneeded services and using SSH in stead of Telnet are still 
> encouraged.
> These assumptions make the analysis fairly simple, along the lines of 
> the COTS protection profile. Individual DCL systems (edge excluded) are 
> not required to be very resistant to determined attack. I'd like to 
> verify that that's true before I start work on this in earnest.
> Ge'

More information about the security_sig mailing list