[Security_sig] Update on CGL Security
Makan.Pourzandi at ericsson.com
Fri Aug 6 16:07:11 PDT 2004
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
> 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?
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