[Security_sig] Update on CGL Security

Makan Pourzandi Makan.Pourzandi at ericsson.com
Fri Aug 6 16:07:11 PDT 2004


Hi Ed,

see my comments in the text.

Ed Reed wrote:
> An example requirement that may require code:
> 
> There is a need to allow unprivileged application services to open
> one or more specific privileged 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?
>

I believe the above is possible by LSM hooks. There is already the 
mechanisms in SE Linux allowing to do so. I believe that it's possible 
to define a policy to allow access to defined ports for the applications 
based on their file context. Am I right?
Furthermore, from what I understood from the above scenario, the DSM 
kernel module which is an open source LSM module does that. I worked on 
that module as part of DSI open source project (disec.sourceforge.net, 
to avoid useless confusion this is not the digital signature lsm module 
(digsig) I did with some other developers). I summarize the way it 
works, first one assigns security IDs to protocol/port numbers (say 
Secure ID A) and to the application (Secure ID B). After that, one needs 
to define a security policy for allowing the access to defined port 
(Secure ID B "can access" Secure ID A). If you need more info I can send 
you more documentation on DSM.

> 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

My understanding is that we should define requirements on the platform, 
c.f. Linux Os or distro, IMO implementing a policy is out of the scope 
of the requirements. Though, the requirement could be that the Linux 
distro should provide us with mechanisms allowing to implement the 
policy to answer/handle the above scenario. Furthermore, without getting 
into discussion on how to implement the above we could always give a 
hint telling that rbac, te and else allow to implement the above and let 
the distro choose what they want.


> transport kernel developers we need this level of control, for
> example, if they don't already provide it?

I believe that netfilter allows to write firewalling rules based on user 
  id, gid, pid.... though I've never used that myself. However, I'm 
afraid the above scenario would be difficult to implement using 
netfilter for different instances of the same application used by 
different users. Any  feedback?

Regards
Makan
> 
> Ed


-- 

Makan Pourzandi, Open Systems Lab
Ericsson Research Canada
*This email does not represent or express the opinions of Ericsson Inc.




More information about the security_sig mailing list