[Security_sig] Update on CGL Security

[Ed Reed]

An example requirement that may require code:

There is a need to allow unpriviledged application services to open
one or more specific priviledged ports in the IP/TCP/UDP stack (for
example), without also having the ability to open other ports that
it should not need to open.

This is an example of a finer grained privilege (to open a particular
port on a particular transport stack) without needing other root
privs.

I'd rather NOT say that the application may have FULL root privs
until after it opens the needed port, at which point it SHOULD
drop other privs it doesnt' need - I'd rather not rely on it
"remembering" to drop unneed privs, because new privs may be created
that it doesn't know it doesn't need to drop.  Rather, I'd prefer
to GRANT the specific priv it DOES need to do the job it's to do,
and NOT grant it others at all.

If capabilities don't provide that granular control, do the LSM
hooks in the IP transport stacks (for instance - this is just one
example) provide the necessary opportunity for controls?

Can we tell folks that they need to implement a policy that let's
them say that, without detailing whether that policy is RBAC,
or TE, or MLS, or SubDomain, or whatever?  Can we tell the IP
transport kernel developers we need this level of control, for
example, if they don't already provide it?

Ed
 
 
>>>Chris Wright <chrisw at osdl.org> 08/05/04 8:58 am >>> 
* Makan Pourzandi (Makan.Pourzandi at ericsson.com) wrote: 
>Gé Weijers wrote: 
>>Hi, 
>> 
>>I'm assuming we're having a security SIG meeting tomorrow. If we don't 
>>or if you cannot attend I'd like to ask you for your opinion on the 
>>following: 
>> 
>>I've studied ITU document "Security in Telecommunications and 
>>Information Technology" in some detail, and I've tentatively drawn the 
>>following conclusions: 
>> 
>>   * telecommunications security is dictated by a host of ITU standards 
>>   * studying a comprehensive subset of them is not feasible 
>>   * the examples given in the ITU document do not have that much in 
>>     common beyond basic mechanisms such as certificates, so a 
>>     generically applicable security analysis is almost impossible. 
>>   * we should therefor limit ourselves to the security of the 
>>     underlying platform. 
> 
>I agree with you. However, we should take into account the 
>characteristics of CGL systems when defining the specs.   Even though, 
>the CG applications are very different, I believe that we should be able 
>to find some general common aspects like high availability for these 
>different applications. I agree that these are rather high level 
>requirements (and sometimes perhaps somehow vague), but if we don't take 
>them into account the NEPs/Linux distros risk not accepting them as 
>valid requirements. For example, we don't want to add a single point of 
>failure into the system, an example of this can be some sort of key 
>storage system that can not support any fail over mechanism. 
 
We also need to make sure such requirements have a reality check. 
Placing the bar too high is not helpful.  Well, OK, I do expect that 
existing failover infrastructure could be enough for key storage. 
 
>>One issue I have not resolved yet is whether the separation between 
>>control plane, management plane and end-user plane (see discussion of 
>>X.805 in ITU doc) is something we should include in our analysis or not. 
> 
>IMO, the security needs for different layers are sometimes completely 
>different. For example, the security needs at management plane are 
>definitely different from the needs at end-user plane. This should be 
>reflected on the analysis, however, we don't want to have different sets 
>of requirements for each plane. What we could do is to explicitly 
>mention them in the document when needed. For example, we could mention 
>that "all communications at __management plane__ should be protected 
>against confidentiality and integrity". 
 
I think it's very reasonable to have requirements that differ in each 
plane. 
 
thanks, 
-chris 
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net 
 
security_sig mailing list 
security_sig at lists.osdl.org 
http://lists.osdl.org/mailman/listinfo/security_sig