TE for networked resources

TE for networked resources

[shahbaz khan]

[-- Attachment #1: Type: text/plain, Size: 612 bytes --]

I was curious while reading Brindle et al paper on enhancing selinux policy
for network domain that do we really need TE for these remote resources.
Can't we just do with IBAC and RBAC? We can let the local subjects handle
the TE with their own types with respect to the IBAC and RBAC of remote
subject. This might be what they call equivalence mechanism. The problems
associated with TE are too tough for selinux and current network controls to
handle. The solutions will cost too much.

Is there any progress on this work. Let me know because I have also working
on this and might be able to assist.

-- 
Shaz

[-- Attachment #2: Type: text/html, Size: 697 bytes --]

Re: TE for networked resources

[Stephen Smalley]

On Thu, 2007-08-16 at 23:47 +0500, shahbaz khan wrote:
> I was curious while reading Brindle et al paper on enhancing selinux
> policy for network domain that do we really need TE for these remote
> resources. Can't we just do with IBAC and RBAC? We can let the local
> subjects handle the TE with their own types with respect to the IBAC
> and RBAC of remote subject. This might be what they call equivalence
> mechanism. The problems associated with TE are too tough for selinux
> and current network controls to handle. The solutions will cost too
> much.

User identity and role doesn't convey enough information - you lose the
binding to the actual program/code.  Which matters.  You want to be able
to allow a given component to interact with another component
specifically, not any arbitrary process running with a given user
identity or role.

> Is there any progress on this work. Let me know because I have also
> working on this and might be able to assist.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: TE for networked resources

[Joshua Brindle]

shahbaz khan wrote:
> I was curious while reading Brindle et al paper on enhancing selinux 
> policy for network domain that do we really need TE for these remote 
> resources. Can't we just do with IBAC and RBAC? We can let the local 
> subjects handle the TE with their own types with respect to the IBAC 
> and RBAC of remote subject. This might be what they call equivalence 
> mechanism. The problems associated with TE are too tough for 
> selinux and current network controls to handle. The solutions will 
> cost too much.
>  
Like Steve said, we want to be able to bind executable code to domains 
most of the time. However, the scheme we proposed leaves the translation 
layer vague intentionally. There is nothing that prevents you from 
making a translation server that only uses IBAC and RBAC.  One potential 
use of this is interacting with non-TE security systems.

> Is there any progress on this work. Let me know because I have also 
> working on this and might be able to assist.

Not as of late. We have the iptools patches in svn but other than that 
nothing much has happened.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: TE for networked resources

[shahbaz khan]

[-- Attachment #1: Type: text/plain, Size: 2561 bytes --]

On 8/17/07, Stephen Smalley <sds@tycho.nsa.gov> wrote:

> On Thu, 2007-08-16 at 23:47 +0500, shahbaz khan wrote:
> > I was curious while reading Brindle et al paper on enhancing selinux
> > policy for network domain that do we really need TE for these remote
> > resources. Can't we just do with IBAC and RBAC? We can let the local
> > subjects handle the TE with their own types with respect to the IBAC
> > and RBAC of remote subject. This might be what they call equivalence
> > mechanism. The problems associated with TE are too tough for selinux
> > and current network controls to handle. The solutions will cost too
> > much.
>
> User identity and role doesn't convey enough information - you lose the
> binding to the actual program/code.  Which matters.  You want to be able
> to allow a given component to interact with another component
> specifically, not any arbitrary process running with a given user
> identity or role.


I think this arbitration can be solved with iptables' rules. A local to
remote port restriction. And further hardened with port labels. Will the
label of ports not be enough? At the required points we still have TE.

TE definitely gives a security granularity at the program/code level but it
is being taken care of by the local system. If the local system ensures it
till its boundaries then the remote subject, handling the requests, can
contain the security problems with its own context and identity and role of
the remote subject.

Sacrificing of the code binding at the cost of reasonable reduction in
complexity, where code binding is mandatory in the boundaries of computer
system but between two systems very little is lost. In the boundaries of the
local system a malicious code cannot get executed with the right policy and
if it does how can TE help to contain it from the remote system if TE
attribute is considered on the remote side? I think identity and role are
enough to contain it on the remote side. The tradeoff will only broaden
risks for the data of that role and identity because it will not consider
its types. Here identity serves as the level of granularity in a specific
role.

Secondly, with SECMARK and IPSEC associations we do pass on the TE attribute
in context. For extra sensitive applications and services, TE can be
considered which means we still reduce the penalty of complexity in policy
maintenance.
Shaz



> > Is there any progress on this work. Let me know because I have also
> > working on this and might be able to assist.
>
> --
> Stephen Smalley
> National Security Agency
>

[-- Attachment #2: Type: text/html, Size: 3193 bytes --]

Re: TE for networked resources

[Stephen Smalley]

On Fri, 2007-08-17 at 02:01 +0500, shahbaz khan wrote:
> On 8/17/07, Stephen Smalley <sds@tycho.nsa.gov > wrote: 
>         On Thu, 2007-08-16 at 23:47 +0500, shahbaz khan wrote:
>         > I was curious while reading Brindle et al paper on enhancing
>         selinux 
>         > policy for network domain that do we really need TE for
>         these remote
>         > resources. Can't we just do with IBAC and RBAC? We can let
>         the local
>         > subjects handle the TE with their own types with respect to
>         the IBAC 
>         > and RBAC of remote subject. This might be what they call
>         equivalence
>         > mechanism. The problems associated with TE are too tough for
>         selinux
>         > and current network controls to handle. The solutions will
>         cost too 
>         > much.
>         
>         User identity and role doesn't convey enough information - you
>         lose the
>         binding to the actual program/code.  Which matters.  You want
>         to be able
>         to allow a given component to interact with another component 
>         specifically, not any arbitrary process running with a given
>         user
>         identity or role.
>  
> I think this arbitration can be solved with iptables' rules. A local
> to remote port restriction. And further hardened with port labels.
> Will the label of ports not be enough? At the required points we still
> have TE.

No, ports aren't adequate for identifying the components.  Think client
side ports and also think dynamic port assignment (ala portmap).

> TE definitely gives a security granularity at the program/code level
> but it is being taken care of by the local system. If the local system
> ensures it till its boundaries then the remote subject, handling the
> requests, can contain the security problems with its own context and
> identity and role of the remote subject.
> 
> Sacrificing of the code binding at the cost of reasonable reduction in
> complexity, where code binding is mandatory in the boundaries of
> computer system but between two systems very little is lost. In the
> boundaries of the local system a malicious code cannot get executed
> with the right policy and if it does how can TE help to contain it
> from the remote system if TE attribute is considered on the remote
> side? I think identity and role are enough to contain it on the remote
> side. The tradeoff will only broaden risks for the data of that role
> and identity because it will not consider its types. Here identity
> serves as the level of granularity in a specific role.
> 
> Secondly, with SECMARK and IPSEC associations we do pass on the TE
> attribute in context. For extra sensitive applications and services,
> TE can be considered which means we still reduce the penalty of
> complexity in policy maintenance.
> 
> Shaz
> 
>  
>         > Is there any progress on this work. Let me know because I
>         have also
>         > working on this and might be able to assist. 
>         
>         --
>         Stephen Smalley
>         National Security Agency
-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: TE for networked resources

[shahbaz khan]

[-- Attachment #1: Type: text/plain, Size: 1600 bytes --]

On 8/17/07, Joshua Brindle <method@manicmethod.com> wrote:
>
> shahbaz khan wrote:
> > I was curious while reading Brindle et al paper on enhancing selinux
> > policy for network domain that do we really need TE for these remote
> > resources. Can't we just do with IBAC and RBAC? We can let the local
> > subjects handle the TE with their own types with respect to the IBAC
> > and RBAC of remote subject. This might be what they call equivalence
> > mechanism. The problems associated with TE are too tough for
> > selinux and current network controls to handle. The solutions will
> > cost too much.
> >
> Like Steve said, we want to be able to bind executable code to domains
> most of the time. However, the scheme we proposed leaves the translation
> layer vague intentionally. There is nothing that prevents you from
> making a translation server that only uses IBAC and RBAC.  One potential
> use of this is interacting with non-TE security systems.


What if we centralize the user and roles and propagate them through Policy
Server? This is a vaguely structured question but you will understand the
possibilities. I can see an ease of management and analysis here. Consider a
centralize policy at the same place for atleast the shared resources.

> Is there any progress on this work. Let me know because I have also
> > working on this and might be able to assist.
>
> Not as of late. We have the iptools patches in svn but other than that
> nothing much has happened.
>
>


-- 
Shaz
Research Associate,
IMSciences, Peshawar,
Pakistan.
Email: shazalive@gmail.com
cell: +92 91 0300 5944647

[-- Attachment #2: Type: text/html, Size: 2178 bytes --]

Re: TE for networked resources

[shahbaz khan]

[-- Attachment #1: Type: text/plain, Size: 3721 bytes --]

On 8/17/07, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>
> On Fri, 2007-08-17 at 02:01 +0500, shahbaz khan wrote:
> > On 8/17/07, Stephen Smalley <sds@tycho.nsa.gov > wrote:
> >         On Thu, 2007-08-16 at 23:47 +0500, shahbaz khan wrote:
> >         > I was curious while reading Brindle et al paper on enhancing
> >         selinux
> >         > policy for network domain that do we really need TE for
> >         these remote
> >         > resources. Can't we just do with IBAC and RBAC? We can let
> >         the local
> >         > subjects handle the TE with their own types with respect to
> >         the IBAC
> >         > and RBAC of remote subject. This might be what they call
> >         equivalence
> >         > mechanism. The problems associated with TE are too tough for
> >         selinux
> >         > and current network controls to handle. The solutions will
> >         cost too
> >         > much.
> >
> >         User identity and role doesn't convey enough information - you
> >         lose the
> >         binding to the actual program/code.  Which matters.  You want
> >         to be able
> >         to allow a given component to interact with another component
> >         specifically, not any arbitrary process running with a given
> >         user
> >         identity or role.
> >
> > I think this arbitration can be solved with iptables' rules. A local
> > to remote port restriction. And further hardened with port labels.
> > Will the label of ports not be enough? At the required points we still
> > have TE.
>
> No, ports aren't adequate for identifying the components.  Think client
> side ports and also think dynamic port assignment (ala portmap).


What about netfilter's connection tracking feature for dynamic port
assignment where labels can be passed to related ports?
We assume that the client is part of the network domain because we also need
to distribute the policy. Thus, the security admin has access to set
iptables and only he is allowed to do so.
Let me check on portmap. But it is'nt an issue as much as I can comprehend
at this time.

Shaz.

> TE definitely gives a security granularity at the program/code level
> > but it is being taken care of by the local system. If the local system
> > ensures it till its boundaries then the remote subject, handling the
> > requests, can contain the security problems with its own context and
> > identity and role of the remote subject.
> >
> > Sacrificing of the code binding at the cost of reasonable reduction in
> > complexity, where code binding is mandatory in the boundaries of
> > computer system but between two systems very little is lost. In the
> > boundaries of the local system a malicious code cannot get executed
> > with the right policy and if it does how can TE help to contain it
> > from the remote system if TE attribute is considered on the remote
> > side? I think identity and role are enough to contain it on the remote
> > side. The tradeoff will only broaden risks for the data of that role
> > and identity because it will not consider its types. Here identity
> > serves as the level of granularity in a specific role.
> >
> > Secondly, with SECMARK and IPSEC associations we do pass on the TE
> > attribute in context. For extra sensitive applications and services,
> > TE can be considered which means we still reduce the penalty of
> > complexity in policy maintenance.
> >
> > Shaz
> >
> >
> >         > Is there any progress on this work. Let me know because I
> >         have also
> >         > working on this and might be able to assist.
> >
> >         --
> >         Stephen Smalley
> >         National Security Agency
> --
> Stephen Smalley
> National Security Agency
>
>

[-- Attachment #2: Type: text/html, Size: 5812 bytes --]

Re: TE for networked resources

[shahbaz khan]

[-- Attachment #1: Type: text/plain, Size: 4208 bytes --]

On 8/17/07, shahbaz khan <shazalive@gmail.com> wrote:
>
>
>
>  On 8/17/07, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> >
> > On Fri, 2007-08-17 at 02:01 +0500, shahbaz khan wrote:
> > > On 8/17/07, Stephen Smalley < sds@tycho.nsa.gov > wrote:
> > >         On Thu, 2007-08-16 at 23:47 +0500, shahbaz khan wrote:
> > >         > I was curious while reading Brindle et al paper on enhancing
> > >         selinux
> > >         > policy for network domain that do we really need TE for
> > >         these remote
> > >         > resources. Can't we just do with IBAC and RBAC? We can let
> > >         the local
> > >         > subjects handle the TE with their own types with respect to
> > >         the IBAC
> > >         > and RBAC of remote subject. This might be what they call
> > >         equivalence
> > >         > mechanism. The problems associated with TE are too tough for
> > >         selinux
> > >         > and current network controls to handle. The solutions will
> > >         cost too
> > >         > much.
> > >
> > >         User identity and role doesn't convey enough information - you
> >
> > >         lose the
> > >         binding to the actual program/code.  Which matters.  You want
> > >         to be able
> > >         to allow a given component to interact with another component
> > >         specifically, not any arbitrary process running with a given
> > >         user
> > >         identity or role.
> > >
> > > I think this arbitration can be solved with iptables' rules. A local
> > > to remote port restriction. And further hardened with port labels.
> > > Will the label of ports not be enough? At the required points we still
> > > have TE.
> >
> > No, ports aren't adequate for identifying the components.  Think client
> > side ports and also think dynamic port assignment (ala portmap).
>
>
> What about netfilter's connection tracking feature for dynamic port
> assignment where labels can be passed to related ports?
>

Ephemeral ports assignment i.e. random port assignment, is a problem if the
program is not already bind()'ed. Correct me if I am wrong. This is also an
issue which selinux needs to address as well. Again its not that difficult
to handle.

 We assume that the client is part of the network domain because we also
> need to distribute the policy. Thus, the security admin has access to set
> iptables and only he is allowed to do so.
> Let me check on portmap. But it is'nt an issue as much as I can comprehend
> at this time.
>
> Shaz.
>
> > TE definitely gives a security granularity at the program/code level
> > > but it is being taken care of by the local system. If the local system
> >
> > > ensures it till its boundaries then the remote subject, handling the
> > > requests, can contain the security problems with its own context and
> > > identity and role of the remote subject.
> > >
> > > Sacrificing of the code binding at the cost of reasonable reduction in
> >
> > > complexity, where code binding is mandatory in the boundaries of
> > > computer system but between two systems very little is lost. In the
> > > boundaries of the local system a malicious code cannot get executed
> > > with the right policy and if it does how can TE help to contain it
> > > from the remote system if TE attribute is considered on the remote
> > > side? I think identity and role are enough to contain it on the remote
> >
> > > side. The tradeoff will only broaden risks for the data of that role
> > > and identity because it will not consider its types. Here identity
> > > serves as the level of granularity in a specific role.
> > >
> > > Secondly, with SECMARK and IPSEC associations we do pass on the TE
> > > attribute in context. For extra sensitive applications and services,
> > > TE can be considered which means we still reduce the penalty of
> > > complexity in policy maintenance.
> > >
> > > Shaz
> > >
> > >
> > >         > Is there any progress on this work. Let me know because I
> > >         have also
> > >         > working on this and might be able to assist.
> > >
> > >         --
> > >         Stephen Smalley
> > >         National Security Agency
> > --
> > Stephen Smalley
> > National Security Agency
> >
> >

[-- Attachment #2: Type: text/html, Size: 6840 bytes --]