Question about integration of IPsec with SELinux?

Question about integration of IPsec with SELinux?

[Park Lee]

Dear sir,

    In SELinux Future Work
(http://www.nsa.gov/selinux/info/todo.cfm),
there is an item which says:"Integrate IPSEC with
network mandatory controls".
I know that it means:"integration of SELinux and IPSEC
for the purpose of labeling and protecting network
packets in accordance with security policy".

     But, Would you please tell me :
Is there any motivation of doing it? What is the
significance of doing it? Where to use it? 
and Is there a scene/scenario for it?

     Thank you very much.


Best Regards,
Park Lee

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

--
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: Question about integration of IPsec with SELinux?

[Casey Schaufler]

--- Park Lee <parklee_sel@yahoo.com> wrote:

> there is an item which says:"Integrate IPSEC with
> network mandatory controls".
> I know that it means:"integration of SELinux and
> IPSEC
> for the purpose of labeling and protecting network
> packets in accordance with security policy".
> 
>      But, Would you please tell me :
> Is there any motivation of doing it? What is the
> significance of doing it? Where to use it? 
> and Is there a scene/scenario for it?

IPSEC is the forward looking mechanism for
passing process attributes between machines.
Without it (or one of the protocols that
preceeded it but have fallen from favor)
there is no way to make access control decisions
on network based communications. You can't
do an MLS cluster, for example, without passing
sensitivity and clearance information among
the machines involved. There are plans afoot
to produce an SELinux based MLS system, and
without networking capabilties the market
opportunity is too small to consider.




Casey Schaufler
casey@schaufler-ca.com


		
__________________________________ 
Discover Yahoo! 
Find restaurants, movies, travel and more fun for the weekend. Check it out! 
http://discover.yahoo.com/weekend.html 


--
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: Question about integration of IPsec with SELinux?

[Park Lee]

On Sat, 11 Jun 2005 at 10:27, Casey Schaufler wrote:

> IPSEC is the forward looking mechanism for
> passing process attributes between machines.

What is the meaning of "forward looking mechanism"?
Why it it called so? 

> Without it (or one of the protocols that
> preceeded it but have fallen from favor)
> there is no way to make access control decisions
> on network based communications. 

Do you mean that we can't make access control
decisions if we do not use IPsec?

> You can't
> do an MLS cluster, for example, without passing
> sensitivity and clearance information among
> the machines involved. There are plans afoot
> to produce an SELinux based MLS system, and
> without networking capabilties the market
> opportunity is too small to consider.

What does "networking capabilities" mean here?


Thank you




Best Regards,
Park Lee


		
__________________________________ 
Discover Yahoo! 
Get on-the-go sports scores, stock quotes, news and more. Check it out! 
http://discover.yahoo.com/mobile.html

--
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: Question about integration of IPsec with SELinux?

[Valdis.Kletnieks]

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

On Sat, 11 Jun 2005 11:45:22 PDT, Park Lee said:
> On Sat, 11 Jun 2005 at 10:27, Casey Schaufler wrote:
> 
> > IPSEC is the forward looking mechanism for
> > passing process attributes between machines.
> 
> What is the meaning of "forward looking mechanism"?
> Why it it called so?

It means that looking into the future, IPSec looks like the best direction
to go.  There's been other protocols, but they don't look as good for the future.

> Do you mean that we can't make access control
> decisions if we do not use IPsec?

No, it means that without IPsec (or other disfavored protocols), you can't
make an access control decision because you need a secure, trustable, and
verifiable way to pass credentials and the like around.

It doesn't *have* to be IPsec - it appears that the OpenSSH protocols also
provide enough of the needed primitives.  It would be a lot harder though,
mostly due to the way that most OpenSSH implementations are mostly done
in userspace, which creates some challenges...

(I'm guessing that OpenSSH was one of the "other protocols" Casey mentioned -
it's *very* useful in it's problem space, but isn't the best choice for *this*
problem (building an MLS cluster)...)
> > You can't
> > do an MLS cluster, for example, without passing
> > sensitivity and clearance information among
> > the machines involved. There are plans afoot
> > to produce an SELinux based MLS system, and
> > without networking capabilties the market
> > opportunity is too small to consider.
> 
> What does "networking capabilities" mean here?

Nobody is interested in doing a single-system MLS that can't talk to the
network (or at least, few enough that there's no market for it).  On the
other hand, if you can deploy it across all the servers in the machine room,
then it gets interesting.

How many people would have deployed Microsoft's Active Directory if it only
worked on a single system?  The only reason it's interesting at all is because
it allows "everything in the department is controlled" management....


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Question about integration of IPsec with SELinux?

[Casey Schaufler]

--- Valdis.Kletnieks@vt.edu wrote:

> (I'm guessing that OpenSSH was one of the "other
> protocols" Casey mentioned -
> it's *very* useful in it's problem space, but isn't
> the best choice for *this*
> problem (building an MLS cluster)...)

The higher level the protocol the fewer system
services (e.g. NFS) that you can use it for.

> > What does "networking capabilities" mean here?
> 
> Nobody is interested in doing a single-system MLS
> that can't talk to the
> network (or at least, few enough that there's no
> market for it).  On the
> other hand, if you can deploy it across all the
> servers in the machine room,
> then it gets interesting.

Valdis has the nut of it.

Perhaps I should have said "facilities" or
"useful features". English is not always a
great language.



Casey Schaufler
casey@schaufler-ca.com


		
__________________________________ 
Discover Yahoo! 
Get on-the-go sports scores, stock quotes, news and more. Check it out! 
http://discover.yahoo.com/mobile.html

--
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: Question about integration of IPsec with SELinux?

[Park Lee]

On Sat, 11 Jun 2005 at 12:49, Casey Schaufler wrote:

> --- Valdis.Kletnieks@vt.edu wrote:
>
>> (I'm guessing that OpenSSH was one of the "other
>> protocols" Casey mentioned -
>> it's *very* useful in it's problem space, but isn't
>> the best choice for *this*
>> problem (building an MLS cluster)...)
>
> The higher level the protocol the fewer system
> services (e.g. NFS) that you can use it for.

If we use OpenSSH, Does it mean that we should send
the data and its security attribute (e.g. sensitivity
and clearance information of the data) together within
a packet? 
and Is there any other way to send security attribute
first and then the date (just like in IPsec case)
except using IPsec?

Thanks,

Best Regards,
Park Lee

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

--
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: Question about integration of IPsec with SELinux?

[Luke Kenneth Casson Leighton]

On Sat, Jun 11, 2005 at 07:16:11PM -0700, Park Lee wrote:
> On Sat, 11 Jun 2005 at 12:49, Casey Schaufler wrote:
> 
> > --- Valdis.Kletnieks@vt.edu wrote:
> >
> >> (I'm guessing that OpenSSH was one of the "other
> >> protocols" Casey mentioned -
> >> it's *very* useful in it's problem space, but isn't
> >> the best choice for *this*
> >> problem (building an MLS cluster)...)
> >
> > The higher level the protocol the fewer system
> > services (e.g. NFS) that you can use it for.
> 
> If we use OpenSSH, Does it mean that we should send
> the data and its security attribute (e.g. sensitivity
> and clearance information of the data) together within
> a packet? 
> and Is there any other way to send security attribute
> first and then the date (just like in IPsec case)
> except using IPsec?
 
 yes, of course there is - you can invent something: make
 something up, yourself.

 ... however, if you look at the requirements carefully, i
 think you will find that IPsec fits most of the requirements
 better than anything else available.

 ... so why bother to go to all the effort of doing _another_ NIH
 syndrome we-can-do-better-than-what-already-exists style of thing.

 
 perhaps a simple way to think of this is that you need an isolated VPN,
 one where nothing but the kernel itself may access it, over which to
 communicate to a centralised security info controller.


 btw i should also raise - again - the wisdom of only utilising
 a 32-bit security descriptor in a networked environment.

 only 32-bit means that if you want to merge or join two secure
 environments together, well.... you basically can't: you have a clash
 of 32-bit SIDs.

 with NT / VAX-VMS style security descriptors (comprising 4of 32-bit
 "SIDs" for a domain and a 32-bit "RID" - relative ID) you can at least
 start creating inter-domain trust relationships.

 ... do you _want_ to create that kind of headache, in advance?

 now's the opportunity to ensure that MLS will be future-proof.

 are there any other alternate solutions to merging two MLS secure
 environments together?

 l.


--
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: Question about integration of IPsec with SELinux?

[Valdis.Kletnieks]

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

On Sun, 12 Jun 2005 12:44:21 BST, Luke Kenneth Casson Leighton said:

>  btw i should also raise - again - the wisdom of only utilising
>  a 32-bit security descriptor in a networked environment.

Should be sufficient in an IPv4 environment, since it's only identifying
the other end.  I'm not awake enough yet - does IPsec on the IPv6 side only
carry 32-bit identifiers too? I'd consider *that* a design whoops...

>  only 32-bit means that if you want to merge or join two secure
>  environments together, well.... you basically can't: you have a clash
>  of 32-bit SIDs.

Oh - the old "merge 2 1918 spaces" problem.. ;)  I suppose suggesting
creative use of a NAT and RFC3489 would get blunt objects heaved in my direction. ;)

>  with NT / VAX-VMS style security descriptors (comprising 4of 32-bit
>  "SIDs" for a domain and a 32-bit "RID" - relative ID) you can at least
>  start creating inter-domain trust relationships.

Once you've established a secure connection to an identified host, there's
nothing stopping you from passing more info down the pipe if the IP 4-tuple
isn't sufficient to provide all the info needed..

>  now's the opportunity to ensure that MLS will be future-proof.
> 
>  are there any other alternate solutions to merging two MLS secure
>  environments together?

I think a useful rephrasing is:

What information needs to be passed when opening an inter-domain trusted
connection, that isn't already available in the IPSec headers?


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Question about integration of IPsec with SELinux?

[Luke Kenneth Casson Leighton]

On Sun, Jun 12, 2005 at 08:39:45AM -0400, Valdis.Kletnieks@vt.edu wrote:
> On Sun, 12 Jun 2005 12:44:21 BST, Luke Kenneth Casson Leighton said:
> 
> >  btw i should also raise - again - the wisdom of only utilising
> >  a 32-bit security descriptor in a networked environment.
> 
> Should be sufficient in an IPv4 environment, since it's only identifying
> the other end.  I'm not awake enough yet

 ha!  you too? :)

> - does IPsec on the IPv6 side only
> carry 32-bit identifiers too? I'd consider *that* a design whoops...
 
 the underlying SIDs of selinux are 32-bit.

 [i do not know about IPsec or IPv6.]

 NT security descriptors are variable-length in multiples of 32-bit -
 anything up to a maximum of... [*guess*] 6x32-bit.

 there are special well-known security descriptors e.g. iirc correctly:
 S-1-0 is "world".

 even a workstation has its own SID "prefix", such that local users and
 local services running on that workstation are uniquely - world-wide -
 identifiable.

 [side-note: the only thing stopping NT 4.0 security from being
 expandable world-wide was the use of a NetBIOS naming scheme
 for name resolution.  if microsoft had obeyed the rfc1001
 and rfc1002 specifications, developed back by IBM somewhere
 in the 1980s iirc, then it would have been possible to map
 MS's NetBIOS implementation properly onto DNS, and they would
 have been off on a winner.  anyway...]


 ... when you only have 32-bit SIDs, as you do in selinux,
 how do you merge two departments or two corporations together,
 _after_ their MLS security has been independently developed?



> >  only 32-bit means that if you want to merge or join two secure
> >  environments together, well.... you basically can't: you have a clash
> >  of 32-bit SIDs.
> 
> Oh - the old "merge 2 1918 spaces" problem.. ;)  I suppose suggesting
> creative use of a NAT and RFC3489 would get blunt objects heaved in my direction. ;)

 well... maybe and maybe not :)

 as long as you are happy to put up with the selinux-sid-NAT table
 expanding out to near-epic proportions...

 ... but it's not _as_ daft as it sounds [at least to me, who came up
 with the SID<->uid/gid-Resolution system for samba]

 just... whatever you do, don't for one second be as stupid
 as the present samba team leadership, and imagine that it's
 okay to do "one-to-many" or "many-to-one" mappings in the
 selinux-sid-NAT tables...

 but the _better_ solution is to have a prefix - on a per-workstation
 basis AND also on a per-... ummm....

 what's a top-level MLS policy called?

 with the word "domain" taken up, which from the "nt domain"
 perspective i _would_ recommend the use of if it wasn't
 already used by selinux "domains"...

 what name should be given to a per-group-of-machines-and-users MLS
 policy?



> >  with NT / VAX-VMS style security descriptors (comprising 4of 32-bit
> >  "SIDs" for a domain and a 32-bit "RID" - relative ID) you can at least
> >  start creating inter-domain trust relationships.
> 
> Once you've established a secure connection to an identified host, there's
> nothing stopping you from passing more info down the pipe if the IP 4-tuple
> isn't sufficient to provide all the info needed..
 
 ah - but how do you say "a local [to me] user when they log
 in to the remote domain must be allowed to run program X"
 when the number for the selinux SID on that remote domain
 utilises the same SID number - for a different purpose?

 are you intending to add in a prefix of some kind, just like
 there is in NT / VAX-VMS security?

> >  now's the opportunity to ensure that MLS will be future-proof.
> > 
> >  are there any other alternate solutions to merging two MLS secure
> >  environments together?
> 
> I think a useful rephrasing is:
> 
> What information needs to be passed when opening an inter-domain trusted
> connection, that isn't already available in the IPSec headers?

 could you possibly help out here by clarifying that we are talking
 about the same thing?

 i don't see what the relevance of the IPsec headers are.

 are you intending the IPsec headers to be the equivalent of the NT /
 VAX-VMS domain "prefix"?

 is there any documentation online that i can read/refer to that will
 help me out, here?

 ta,

 l.


--
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: Question about integration of IPsec with SELinux?

[Valdis.Kletnieks]

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

On Sun, 12 Jun 2005 16:20:38 BST, Luke Kenneth Casson Leighton said:

>  the underlying SIDs of selinux are 32-bit.

Whoops. I forgot about that. ;)

>  [i do not know about IPsec or IPv6.]

The 'spi' field in the ip_auth_hdr and ip_esp_hdr is a u32, which is what
I was thinking of...

>  ... when you only have 32-bit SIDs, as you do in selinux,
>  how do you merge two departments or two corporations together,
>  _after_ their MLS security has been independently developed?

We just rely on the magic of sidtab_context_to_sid() -  it's basically
handed something that looks like a 'foo_u:bar_r:baz_t' and cranks out a
new SID, which is only used in the kernel.  As long as the merger of the
two systems doesn't require more total SID's than a u32 can represent,
there's no problem.

You however *do* need to adress collisions between two different foo_u ;)

>  ah - but how do you say "a local [to me] user when they log
>  in to the remote domain must be allowed to run program X"
>  when the number for the selinux SID on that remote domain
>  utilises the same SID number - for a different purpose?

The SIDs are locally generated on the fly. It's the *CONTEXT* that might
be in use elsewhere.  You'd basically want to make sure that on-the-wire you
always pass around a context label rather than a SID.

You'll want *some* way of managing the allocation of contexts cluster-wide,
just so you don't have two usages of jdoe_u that refer to two different users..

>  are you intending to add in a prefix of some kind, just like
>  there is in NT / VAX-VMS security?

Might be worth looking into..

> > What information needs to be passed when opening an inter-domain trusted
> > connection, that isn't already available in the IPSec headers?
> 
>  could you possibly help out here by clarifying that we are talking
>  about the same thing?

You already clarified that we weren't.. ;)

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Question about integration of IPsec with SELinux?

[Luke Kenneth Casson Leighton]

On Sun, Jun 12, 2005 at 03:18:42PM -0400, Valdis.Kletnieks@vt.edu wrote:
> On Sun, 12 Jun 2005 16:20:38 BST, Luke Kenneth Casson Leighton said:
> 
> >  the underlying SIDs of selinux are 32-bit.
> 
> Whoops. I forgot about that. ;)

 :)  but hey, like you point out, it's not the SIDs that are the
 critical bits, it's the context "name" - string.


> >  [i do not know about IPsec or IPv6.]
> 
> The 'spi' field in the ip_auth_hdr and ip_esp_hdr is a u32, which is what
> I was thinking of...
> 
> >  ... when you only have 32-bit SIDs, as you do in selinux,
> >  how do you merge two departments or two corporations together,
> >  _after_ their MLS security has been independently developed?
> 
> We just rely on the magic of sidtab_context_to_sid() -  it's basically
> handed something that looks like a 'foo_u:bar_r:baz_t' and cranks out a
> new SID, which is only used in the kernel.  As long as the merger of the
> two systems doesn't require more total SID's than a u32 can represent,
> there's no problem.
> 
> You however *do* need to adress collisions between two different foo_u ;)
 
 ah _ha_.  there y'go.


> >  ah - but how do you say "a local [to me] user when they log
> >  in to the remote domain must be allowed to run program X"
> >  when the number for the selinux SID on that remote domain
> >  utilises the same SID number - for a different purpose?
> 
> The SIDs are locally generated on the fly. It's the *CONTEXT* that might
> be in use elsewhere.  You'd basically want to make sure that on-the-wire you
> always pass around a context label rather than a SID.
 
 okay.  cool.

> You'll want *some* way of managing the allocation of contexts cluster-wide,
> just so you don't have two usages of jdoe_u that refer to two different users..
> 
> >  are you intending to add in a prefix of some kind, just like
> >  there is in NT / VAX-VMS security?
> 
> Might be worth looking into..

 well, if you're going to follow the convention of passing around the
 context [as a string] then you might as well continue with that
 tradition...

 i dunno... say, by adding @hostname or @dns.domain.name

 e.g. foo_u:bar_r:baz_t@toplevelmlsgroup.mycompany.co.uk or
 foo_u:bar_r:baz_t@myworkstation.mycompany.co.uk


> > > What information needs to be passed when opening an inter-domain trusted
> > > connection, that isn't already available in the IPSec headers?
> > 
> >  could you possibly help out here by clarifying that we are talking
> >  about the same thing?
> 
> You already clarified that we weren't.. ;)

oh. i did?  glad to be of help, then.  um :)  

l.

-- 
--
<a href="http://lkcl.net">http://lkcl.net</a>
--

--
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: Question about integration of IPsec with SELinux?

[Valdis.Kletnieks]

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

On Sun, 12 Jun 2005 21:25:39 BST, Luke Kenneth Casson Leighton said:

>  well, if you're going to follow the convention of passing around the
>  context [as a string] then you might as well continue with that
>  tradition...
> 
>  i dunno... say, by adding @hostname or @dns.domain.name
> 
>  e.g. foo_u:bar_r:baz_t@toplevelmlsgroup.mycompany.co.uk or
>  foo_u:bar_r:baz_t@myworkstation.mycompany.co.uk

Much as I hate to admit it, Microsoft got this one right, with their AD
tree structure - you don't want to drag a machine name around, you want to
drag around an 'ou=' type thing that describes the *logical* role of the
entity.  Remember, you probably care more that I'm connecting as "a sysadmin
in this department" than the actual host I'm connecting from (assuming of course
that all hosts I'm connecting from are part of the cluster)....

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Question about integration of IPsec with SELinux?

[Luke Kenneth Casson Leighton]

On Sun, Jun 12, 2005 at 09:25:39PM +0100, Luke Kenneth Casson Leighton wrote:
> > >  are you intending to add in a prefix of some kind, just like
> > >  there is in NT / VAX-VMS security?
> > 
> > Might be worth looking into..
> 
>  well, if you're going to follow the convention of passing around the
>  context [as a string] then you might as well continue with that
>  tradition...
> 
>  i dunno... say, by adding @hostname or @dns.domain.name
> 
>  e.g. foo_u:bar_r:baz_t@toplevelmlsgroup.mycompany.co.uk or
>  foo_u:bar_r:baz_t@myworkstation.mycompany.co.uk
 
 just an additional thought - i think people would _hate_ to
 have to add @thingy... in front of every single type.

 from a compilation perspective it might be best to be
 able to specify a default dns domain name as part of the
 /etc/selinux/src/policy/.... config and to accept "exceptions" to this
 in a grouping syntax:

 @mls-external-domain=someoneelsesworkstation.mycompany.com
 {
 	allow foo_t ...
 	allow bar_t ...
 }

 as an understandable simplification for:

 allow foo_t@mls-external-domain=someoneelsesworkstation.mycompany.com ...
 allow bar_t@mls-external-domain=someoneelsesworkstation.mycompany.com ...

 that way it minimises the impact on single-workstation systems.


 ... you have _no_ idea how delighted i would be to see this in
 operation.

 linux finally catching up with nt after nearly 20 years,
 sticking one in MS's eye, having a security model that
 surpasses NT domains.

 ... of course, i wouldn't expect its configuration and setup
 to be easy, of _course_ i'd expect configuration to involve
 flat text files.

 teehee.

 l.


--
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: Question about integration of IPsec with SELinux?

[Valdis.Kletnieks]

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

On Sun, 12 Jun 2005 21:52:29 BST, you said:

>  ... of course, i wouldn't expect its configuration and setup
>  to be easy, of _course_ i'd expect configuration to involve
>  flat text files.

Any site that does anything like this will find it's not easy, and that
many of the *hard* parts are political, not technical (as we found out
several years ago when we did our AD rollout - the *hard* part was all
the meetings where people got to fight over who did and didn't need access
to what resources.

I actually don't care about flat files - I care that I have (a) some sort of
a viewer to let me browse/debug, and (b) a way for Perl to read the files...

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Question about integration of IPsec with SELinux?

[Stephen Smalley]

On Sun, 2005-06-12 at 21:25 +0100, Luke Kenneth Casson Leighton wrote:
>  well, if you're going to follow the convention of passing around the
>  context [as a string] then you might as well continue with that
>  tradition...
> 
>  i dunno... say, by adding @hostname or @dns.domain.name
> 
>  e.g. foo_u:bar_r:baz_t@toplevelmlsgroup.mycompany.co.uk or
>  foo_u:bar_r:baz_t@myworkstation.mycompany.co.uk

No; you want a separate notion of policy domain of interpretation (DOI),
which is a separate component of the security association (not the
security context).

-- 
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: Question about integration of IPsec with SELinux?

[Luke Kenneth Casson Leighton]

On Mon, Jun 13, 2005 at 09:00:37AM -0400, Stephen Smalley wrote:
> On Sun, 2005-06-12 at 21:25 +0100, Luke Kenneth Casson Leighton wrote:
> >  well, if you're going to follow the convention of passing around the
> >  context [as a string] then you might as well continue with that
> >  tradition...
> > 
> >  i dunno... say, by adding @hostname or @dns.domain.name
> > 
> >  e.g. foo_u:bar_r:baz_t@toplevelmlsgroup.mycompany.co.uk or
> >  foo_u:bar_r:baz_t@myworkstation.mycompany.co.uk
> 
> No; you want a separate notion of policy domain of interpretation (DOI),
> which is a separate component of the security association (not the
> security context).
 
 stephen, hi,

 thanks for replying: is there any where that contains a glossary of
 terms, such that i can follow discussions / make comments without
 floundering around any more than i usually do?

 ta,

 l.


--
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: Question about integration of IPsec with SELinux?

[Stephen Smalley]

On Mon, 2005-06-13 at 22:16 +0100, Luke Kenneth Casson Leighton wrote:
>  thanks for replying: is there any where that contains a glossary of
>  terms, such that i can follow discussions / make comments without
>  floundering around any more than i usually do?

A glossary, no.  Some concepts are discussed in 
http://www.cs.utah.edu/flux/papers/ajay-thesis-abs.html

-- 
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: Question about integration of IPsec with SELinux?

[Trent Jaeger]

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

Hi,

Also, I should have an IBM technical report on the Linux IPSec-LSM-SELinux 
integration available soon.   I will post to the list when it is 
available.

Regards,
Trent.
------------------------------------------------------------
Trent Jaeger
IBM T.J. Watson Research Center
19 Skyline Drive, Hawthorne, NY 10532
(914) 784-7225, FAX (914) 784-7225




Stephen Smalley <sds@tycho.nsa.gov>
Sent by: owner-selinux@tycho.nsa.gov
06/14/2005 09:21 AM
 
        To:     Luke Kenneth Casson Leighton <lkcl@lkcl.net>
        cc:     Valdis.Kletnieks@vt.edu, Park Lee <parklee_sel@yahoo.com>, 
Casey Schaufler <casey@schaufler-ca.com>, SELinux <SELinux@tycho.nsa.gov>
        Subject:        Re: Question about integration of IPsec with 
SELinux?


On Mon, 2005-06-13 at 22:16 +0100, Luke Kenneth Casson Leighton wrote:
>  thanks for replying: is there any where that contains a glossary of
>  terms, such that i can follow discussions / make comments without
>  floundering around any more than i usually do?

A glossary, no.  Some concepts are discussed in 
http://www.cs.utah.edu/flux/papers/ajay-thesis-abs.html

-- 
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.


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

Re: Question about integration of IPsec with SELinux?

[Luke Kenneth Casson Leighton]

thank you, both!


On Tue, Jun 14, 2005 at 10:31:53AM -0400, Trent Jaeger wrote:

> > Also, I should have an IBM technical report on the Linux IPSec-LSM-SELinux 
> > integration available soon.   I will post to the list when it is 
> > available.

> A glossary, no.  Some concepts are discussed in 
> http://www.cs.utah.edu/flux/papers/ajay-thesis-abs.html
> 
> -- 
> 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: Question about integration of IPsec with SELinux?

[Casey Schaufler]

--- Valdis.Kletnieks@vt.edu wrote:


> You'll want *some* way of managing the allocation of
> contexts cluster-wide,
> just so you don't have two usages of jdoe_u that
> refer to two different users..

You will do well to consider the implications
of allowing anything other than identical policies
within a cluster or even a grid. Dealing with
something as simple as the difference between
DoD Secret and DoE Secret is a real challange.
Back in the days of CMW Mitre produced a language
for mapping security contexts between systems
that did little but demonstrate why you don't
want to try it. Sure, it's doable for small
policies (Bell and La Padula or Biba for example)
but a policy that includes over 40,000 explicit
rules? That would be a challange. Further, if
you're mapping a 40k policy to a different 40k
policy, well, "do the math", as they say.
 


Casey Schaufler
casey@schaufler-ca.com

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

--
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: Question about integration of IPsec with SELinux?

[Valdis.Kletnieks]

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

On Sun, 12 Jun 2005 16:32:33 PDT, Casey Schaufler said:

> You will do well to consider the implications
> of allowing anything other than identical policies
> within a cluster or even a grid. Dealing with
> something as simple as the difference between
> DoD Secret and DoE Secret is a real challange.

Exactly.  This is the most sane way to approach it.

The fun starts when you've got two existing systems and need to
modify the policies so they're identical.

We'll also probably be needing to address the memory consumption issues
again - the current system will go totally bonkers if you have a large
(5K-10K and up) number of different FOO_u roles defined (particularly
messy if you have a large diverse cluster and lots of people who have needs
to use only a few nodes of the cluster.  Possibly the loadable-policy stuff
can be used to load/unload a given user's policy at login/out?

(I'm thinking that this has to be able to play in the same arena as
MS's AD for department-scale management, for lots of nodes under one
administrative control, but not a set of cookie-cutter nodes like in the
usual compute cluster - if others are thinking different goals, they
better speak up now before the un-noticed divergence confuses us all.. ;)

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Question about integration of IPsec with SELinux?

[Luke Kenneth Casson Leighton]

On Sun, Jun 12, 2005 at 04:32:33PM -0700, Casey Schaufler wrote:
> 
> --- Valdis.Kletnieks@vt.edu wrote:
> 
> 
> > You'll want *some* way of managing the allocation of
> > contexts cluster-wide,
> > just so you don't have two usages of jdoe_u that
> > refer to two different users..
> 
> You will do well to consider the implications
> of allowing anything other than identical policies
> within a cluster or even a grid. 

 okay.

 simplistic view: in nt-land, you have local workstations
 'policy' and you have a global 'policy'.



 the local workstations' policies are typically set up to
 allow a local admin to log in to the machine, etc. using the
 local SAM database (and you select the workstation domain /
 local SAM by selecting the workstation's name on the login
 dialog box to do that).

 what you DO NOT DO is add any permissions into the local SAM database
 for any local users to be able to access any of the domain resources.

 in this way you have a scheme whereby the workstation is still
 to some extent useable / recoverable even when disconnected
 (isolated) from the domain.

 do you _really_ want a domain-wide policy that specifies
 "only the domain admin has the manage the network interfaces"?

 because what happens if there _is_ no network by which you can access
 or validate the domain policy such that you can trouble-shoot the
 network interface?

 !!!

 
 even though it's access-control based, there is much to be
 learned from the application of microsoft's nt domain protocol.

 l.


--
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: Question about integration of IPsec with SELinux?

[Valdis.Kletnieks]

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

On Mon, 13 Jun 2005 11:01:58 BST, Luke Kenneth Casson Leighton said:

>  because what happens if there _is_ no network by which you can access
>  or validate the domain policy such that you can trouble-shoot the
>  network interface?

The guys who build Juniper routers have an interesting solution for that - when
yo make a config change, it doesn't go permanently live.  If you don't enter a
*second* 'commit' command, after 5 mins or so it auto-reverts to the previous
config.  Really handy when you bork a routing table and hose your SSH session
into the router - our IOS guys immediaely made that their number 1 "We wish
Cisco did this too.." request ;)


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Question about integration of IPsec with SELinux?

[Casey Schaufler]

--- Luke Kenneth Casson Leighton <lkcl@lkcl.net>
wrote:


> > You will do well to consider the implications
> > of allowing anything other than identical policies
> > within a cluster or even a grid. 
> 
>  okay.
> 
>  simplistic view: in nt-land, you have local
> workstations
>  'policy' and you have a global 'policy'.

The "one policy" ought to allow for the 
differentiation between local and global
without resorting to naming each individual
machine explicitly. Clusters typically name
the nodes dynamicaly after all.

>  in this way you have a scheme whereby the
> workstation is still
>  to some extent useable / recoverable even when
> disconnected
>  (isolated) from the domain.

Does it make sense for a machine that is part
of a global "system" to have a policy that is
potentially inconsistent with the whole? Maybe.
Your are definitely getting into one of the areas
that can cause trouble. User Wilma defined in
two places differently because there are two of
her. Since users are in the policy, you have a
sticky issue.


>  even though it's access-control based, there is
> much to be
>  learned from the application of microsoft's nt
> domain protocol.

Learning from the experience of
others is for squares.


Casey Schaufler
casey@schaufler-ca.com


		
__________________________________ 
Discover Yahoo! 
Find restaurants, movies, travel and more fun for the weekend. Check it out! 
http://discover.yahoo.com/weekend.html 


--
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: Question about integration of IPsec with SELinux?

[Stephen Smalley]

On Sun, 2005-06-12 at 16:20 +0100, Luke Kenneth Casson Leighton wrote:
>  the underlying SIDs of selinux are 32-bit.
<snip>
>  ... when you only have 32-bit SIDs, as you do in selinux,
>  how do you merge two departments or two corporations together,
>  _after_ their MLS security has been independently developed?

SIDs are node-local and non-persistent (and now kernel-private)
identifiers.  Complete non-issue.

For a CIPSO-style implementation like the Selopt implementation by James
Morris for the old SELinux, you can store the SID in the option and then
perform translation on the receiving host based on a network SID cache
that maps (source address, SID) pairs to local SIDs, using a userspace
security context mapping daemon to get the actual security context if
the network SID isn't already cached.

For IPSEC, there is no explicit label in the packet, just the SPI that
indicates the IPSEC security association, and that contains the security
context/SID information that was exchanged when the SA was set up.

-- 
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: Question about integration of IPsec with SELinux?

[Luke Kenneth Casson Leighton]

On Mon, Jun 13, 2005 at 08:49:53AM -0400, Stephen Smalley wrote:
> On Sun, 2005-06-12 at 16:20 +0100, Luke Kenneth Casson Leighton wrote:
> >  the underlying SIDs of selinux are 32-bit.
> <snip>
> >  ... when you only have 32-bit SIDs, as you do in selinux,
> >  how do you merge two departments or two corporations together,
> >  _after_ their MLS security has been independently developed?
> 
> SIDs are node-local and non-persistent (and now kernel-private)
> identifiers.  Complete non-issue.
 
 *sigh* yes, it took valdis and i a couple of rounds of email
 on sunday to establish / remind ourselves of that.

 
> For a CIPSO-style implementation like the Selopt implementation by James
> Morris for the old SELinux, you can store the SID in the option and then
> perform translation on the receiving host based on a network SID cache
> that maps (source address, SID) pairs to local SIDs, using a userspace
> security context mapping daemon to get the actual security context if
> the network SID isn't already cached.
 
 ah HA!  so there exists something that does ... sort-of-NAT, already?
 GREAT!



--
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: Question about integration of IPsec with SELinux?

[Stephen Smalley]

On Sun, 2005-06-12 at 12:44 +0100, Luke Kenneth Casson Leighton wrote:
>  btw i should also raise - again - the wisdom of only utilising
>  a 32-bit security descriptor in a networked environment.
> 
>  only 32-bit means that if you want to merge or join two secure
>  environments together, well.... you basically can't: you have a clash
>  of 32-bit SIDs.
> 
>  with NT / VAX-VMS style security descriptors (comprising 4of 32-bit
>  "SIDs" for a domain and a 32-bit "RID" - relative ID) you can at least
>  start creating inter-domain trust relationships.

As is clearly noted in all SELinux documentation, SIDs are purely non-
global (node-local) and non-persistent handles to security contexts.
And as of Linux 2.6, they are furthermore kernel-private (or in the case
of the userspace AVC, application-private).

-- 
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: Question about integration of IPsec with SELinux?

[Luke Kenneth Casson Leighton]

On Mon, Jun 13, 2005 at 08:37:10AM -0400, Stephen Smalley wrote:
> On Sun, 2005-06-12 at 12:44 +0100, Luke Kenneth Casson Leighton wrote:
> >  btw i should also raise - again - the wisdom of only utilising
> >  a 32-bit security descriptor in a networked environment.
> > 
> >  only 32-bit means that if you want to merge or join two secure
> >  environments together, well.... you basically can't: you have a clash
> >  of 32-bit SIDs.
> > 
> >  with NT / VAX-VMS style security descriptors (comprising 4of 32-bit
> >  "SIDs" for a domain and a 32-bit "RID" - relative ID) you can at least
> >  start creating inter-domain trust relationships.
> 
> As is clearly noted in all SELinux documentation, SIDs are purely non-
> global (node-local) and non-persistent handles to security contexts.
> And as of Linux 2.6, they are furthermore kernel-private (or in the case
> of the userspace AVC, application-private).

 so the security "context" label string is equivalent to an NT "RID".

 and - just to clarify: the DOI - domain of interpretation -
 is equivalent to the NT domain "prefix"?

 cheers,

 l.


--
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: Question about integration of IPsec with SELinux?

[Valdis.Kletnieks]

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

On Sat, 11 Jun 2005 19:16:11 PDT, Park Lee said:
> If we use OpenSSH, Does it mean that we should send
> the data and its security attribute (e.g. sensitivity
> and clearance information of the data) together within
> a packet?

That of course depends on whether the protocol you're trying to secure requires
labelling each packet, or whether labelling a connection at setup is
sufficient.  This is similar, but subtly different, from the distinction
between UDP and TCP - if you're doing NFS over TCP, you still need to pass
security attributes along with each transaction...

Not that I'd actually *recommend* using OpenSSH for this - I gave it as an
example of something that *theoretically* provided low-level primitives
(basically, the ability to open up a tunnel and have some crypto protecting
against eavesdroppers and verifying the other end's identity).

OpenSSH and OpenSSL *both* suffer from the very real *practical* problem
that their connections terminate in userspace, while IPsec terminates
connections in the kernel.  While this is *not* an issue for the class of
problems that OpenSS[HL] were designed to address, it's got some *major*
issues when trying to build an MLS system out of it.

By the time you'd finish beating up the code for something else, it would look
an awful lot like IPSec *anyhow*....

> and Is there any other way to send security attribute
> first and then the date (just like in IPsec case)
> except using IPsec?

Are there any other ways? Sure.

Are there any other *reasonable* ways? Probably not.

You *could* go and write your own protocol and code to handle it and test it
and get other cryptographers to double-check your work and make sure you did
it right - or you can do what any *reasonable* programmer would do and use
the already provided and tested IPSec code. ;)



[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Question about integration of IPsec with SELinux?

[Luke Kenneth Casson Leighton]

On Sun, Jun 12, 2005 at 08:34:54AM -0400, Valdis.Kletnieks@vt.edu wrote:

> OpenSSH and OpenSSL *both* suffer from the very real *practical* problem
> that their connections terminate in userspace, while IPsec terminates
> connections in the kernel.  


 ah - there _is_ a way round that: to use something like tun/tap.

 there's a VPN project i forget the name of... tinc, yes, it's called
 tinc.

 it's an entirely userspace VPN.

 it would, imo, be perfectly reasonable to add into tun/tap a means to
 pass selinux avc queries etc. over that.

 ... heck - why not? :)

 l.

 p.s. i _hate_ the concept of doing this kind of high-level
 work in userspace.  i _wish_ linus wasn't so damn stupidly pig-headed
 about monolithic kernels.  all this stuff would be _so_ much less
 hassle and so much a non-issue on top of an L4 microkernel or in the
 GNU/Hurd.


--
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: Question about integration of IPsec with SELinux?

[Park Lee]

On Sun, 12 Jun 2005 at 08:34, Valdis.Kletnieks@vt.edu
wrote:
>> and Is there any other way to send security
>> attribute first and then the date (just like in 
>> IPsec case) except using IPsec?
>
> Are there any other ways? Sure.
 
Would you please show me some already existing ways?

Thank you.


Best Regards,
Park Lee

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

--
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: Question about integration of IPsec with SELinux?

[Casey Schaufler]

--- Park Lee <parklee_sel@yahoo.com> wrote:
 
> ... Is there any other way to send security
> attribute
> first and then the date (just like in IPsec case)
> except using IPsec?

CIPSO provides sufficient mechanism to do this.
There are also the TSIG TSIX protocols, but I
seriously doubt you'd want to invest heavily in
those with IPSEC around.



Casey Schaufler
casey@schaufler-ca.com


		
__________________________________ 
Discover Yahoo! 
Find restaurants, movies, travel and more fun for the weekend. Check it out! 
http://discover.yahoo.com/weekend.html 


--
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: Question about integration of IPsec with SELinux?

[Park Lee]

Best Regards,
Park Lee

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

--
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: Question about integration of IPsec with SELinux?

[Park Lee]

Hi,
First, I'm sorry for my missending a blank letter just
now.

On Sat, 11 Jun 2005 at 10:27, Casey Schaufler wrote:
> --- Park Lee <parklee_sel@yahoo.com> wrote:
>
>> there is an item which says:"Integrate IPSEC with
>> network mandatory controls".
>> I know that it means:"integration of SELinux and
>> IPSEC
>> for the purpose of labeling and protecting network
>> packets in accordance with security policy".
>> 
>>      But, Would you please tell me :
>> Is there any motivation of doing it? What is the
>> significance of doing it? Where to use it? 
>> and Is there a scene/scenario for it?
>
> IPSEC is the forward looking mechanism for
> passing process attributes between machines.
> Without it (or one of the protocols that
> preceeded it but have fallen from favor)
> there is no way to make access control decisions
> on network based communications. You can't
> do an MLS cluster, for example, without passing
> sensitivity and clearance information among
> the machines involved.

But, when we "Integrate IPSEC with network mandatory
controls", we only label and protect _network_
_packets_, How can we control _processes_ in network
circumstance?

and, Can I view what you wrote as a application of
"labeled networking"
which is mentioned by James Morris in
http://www.linuxjournal.com/article/7764 ?
then, What is the purpose of a "labeled networking"?


Thanks a lot. 





Best Regards,
Park Lee

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

--
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: Question about integration of IPsec with SELinux?

[Casey Schaufler]

--- Park Lee <parklee_sel@yahoo.com> wrote:


> But, when we "Integrate IPSEC with network mandatory
> controls", we only label and protect _network_
> _packets_, How can we control _processes_ in network
> circumstance?

Hum. Allow me to make sure we've got fundimentals
covered before I try answering this.

A system compares attributes of processes such
as user IDs, group memberships, clearances, and
domain affiliations with attributes of storage
containers such as ownership, sensitivity, and
access control lists to determine what accesses
may be permitted. An interesting special case of
this behavior is interprocess communication,
in which the sending process treats the receiving
process as a storage container. In the local
system case, where both the sending process and
the receiving process are on the same machine,
the attributes relevent to an access decision are
available, and the IPC mechanism can make the call
without special accomodation. If the processes
are on different machines the IPC mechanism must
provide transport of the required attributes so
that the decision can be made.

> and, Can I view what you wrote as a application of
> "labeled networking"
> which is mentioned by James Morris in
> http://www.linuxjournal.com/article/7764 ?
> then, What is the purpose of a "labeled networking"?

Labeled networking is an implementation of
mechanism to provide sufficient attribute
information for the TCP/IP and UDP/IP IPC
mechanisms to be useful in an environment
that requires all IPC mechanisms provide access
control. This includes the LSPP specification
of the Common Criteria.

Labeled networking is not new. SGI and Cray
completed B1 evaluations in 1995 that used CIPSO.
The SGI system looked like a cluster where
Cray chose to treat their machine as a single
network component.



Casey Schaufler
casey@schaufler-ca.com

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

--
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: Question about integration of IPsec with SELinux?

[Casey Schaufler]

--- Luke Kenneth Casson Leighton <lkcl@lkcl.net>
wrote:


>  wilma@DOI1 has **nothing** to do with wilma@DOI2.

This is the sort of thing that seperates the
developers from the admins. Of course wilma@DOI1
isn't wilma@DOI2. Nonetheless, reams of
documentation and countless warnings
notwithstanding, the human that creates the mapping
between DOI1 and DOI2 will 99 44/100% of the time
map wilma directly to wilma. It's bad enough for
usernames. I see no reason to expect it to be
any better for policy constructs.

Username mapping errors are bad, but one or the
other of the individuals involved usually detects
the problem quickly enough. I don't know that I'd
expect the same to be true of policy elements.



Casey Schaufler
casey@schaufler-ca.com


		
__________________________________ 
Yahoo! Mail Mobile 
Take Yahoo! Mail with you! Check email on your mobile phone. 
http://mobile.yahoo.com/learn/mail 

--
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: Question about integration of IPsec with SELinux?

[Luke Kenneth Casson Leighton]

On Mon, Jun 13, 2005 at 03:03:28PM -0700, Casey Schaufler wrote:
> 
> 
> --- Luke Kenneth Casson Leighton <lkcl@lkcl.net>
> wrote:
> 
> 
> >  wilma@DOI1 has **nothing** to do with wilma@DOI2.
> 
> This is the sort of thing that seperates the
> developers from the admins. Of course wilma@DOI1
> isn't wilma@DOI2. Nonetheless, reams of
> documentation and countless warnings
> notwithstanding, the human that creates the mapping
> between DOI1 and DOI2 will 99 44/100% of the time
> map wilma directly to wilma. It's bad enough for
> usernames. I see no reason to expect it to be
> any better for policy constructs.

 everyone sees "Administrator" on local workstations.

 do they _genuinely_ believe that "Administrator" on workstation
 1 is the same as "Administrator" on workstation 2??

 ... but anyway: the lessons there should be learned from the
 way that nt's "active directory" infrastructure is managed.

 if it's dumb enough for nt admins to not screw up...


--
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: Question about integration of IPsec with SELinux?

[Brian T. Sniffen]

Casey Schaufler <casey@schaufler-ca.com> writes:

> Username mapping errors are bad, but one or the
> other of the individuals involved usually detects
> the problem quickly enough. I don't know that I'd
> expect the same to be true of policy elements.

We already see admins doing this regularly: they drop a file from Red
Hat's strict policy into the their Fedora system using Targeted
policy, or from Fedora onto a Debian system, and are surprised when it
does not work.

The average userbase will always expect user_t and httpd_t to mean the
same things everywhere, even though they will not.  It's because of
this difficulty that polgen does only structural analysis, ignoring
accidents of naming.  We're having enough trouble adapting our output
to the evolving details of policy differences (e.g., unconfined_t vs. user_t).

-Brian


--
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: Question about integration of IPsec with SELinux?

[Park Lee]

On Sun, 12 Jun 2005 at 10:46, Casey Schaufler wrote:

> A system compares attributes of processes such
> as user IDs, group memberships, clearances, and
> domain affiliations with attributes of storage
> containers such as ownership, sensitivity, and
> access control lists to determine what accesses
> may be permitted. An interesting special case of
> this behavior is interprocess communication,
> in which the sending process treats the receiving
> process as a storage container. In the local
> system case, where both the sending process and
> the receiving process are on the same machine,
> the attributes relevent to an access decision are
> available, and the IPC mechanism can make the call
> without special accomodation. If the processes
> are on different machines the IPC mechanism must
> provide transport of the required attributes so
> that the decision can be made.


Now let's suppose that processes are on different
machines,
Do you mean that attributes of receiving process
should be sent to the sending machine, which
contains the sending process? and the access control
are made on the sending machine to decide
whether the sending process can do interprocess
communication with its receiving process?
Can we view the sending process as a subject,and view
the receiving process as an object in the interprocess
communication on different machines?

If it is, let's see another situation:
We use the attributes of the sending process to label
the packets which are sent by the sending
process. when the packets are received on receiving
machine, the receiving machine can use the
attributes of the receiving process and the attributes
of the packets to determine whether these packets can
be received. Here, the receiving process becomes
subject, and the packets which represent its sending
process become objects. 
Then, Does this situation become conflict with what
you wrote above?


Thanks a lot.



Best Regards,
Park Lee


		
__________________________________ 
Do you Yahoo!? 
Make Yahoo! your home page 
http://www.yahoo.com/r/hs

--
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: Question about integration of IPsec with SELinux?

[Casey Schaufler]

--- Park Lee <parklee_sel@yahoo.com> wrote:

> On Sun, 12 Jun 2005 at 10:46, Casey Schaufler wrote:
> 
> > A system compares ... the decision can be made.
> 
> Now let's suppose that processes are on different
> machines,

Yup.

> Do you mean that attributes of receiving process
> should be sent to the sending machine, which
> contains the sending process?

You'd have to anticipate what attributes
of what objects would be needed before you
could send packets. Beyond current technology.

> and the access control
> are made on the sending machine to decide
> whether the sending process can do interprocess
> communication with its receiving process?

Again, if you could get the attributes of all
the receivers onto the sender in a reliable way
that would be great.

> Can we view the sending process as a subject,
> and view the receiving process as an object
> in the interprocess communication on different
> machines?

Yes, although it is traditional to use
the receiver side socket as the object
rather than the receiving process. This
is done to allow privileged processes
to set socket attributes that allow
delivery of packets with attributes that
would normally be disallowed.

> If it is, let's see another situation:
> We use the attributes of the sending process to
> label
> the packets which are sent by the sending
> process.

This is the typical scenario.

> when the packets are received on receiving
> machine, the receiving machine can use the
> attributes of the receiving process and the
> attributes
> of the packets to determine whether these packets
> can
> be received.

This is the way Unix systems using CIPSO
and/or TSIG SAMP work.

> Here, the receiving process becomes
> subject, and the packets which represent its sending
> process become objects. 

Well, not quite. In this scenario the sending
process is still the subject and the receiving
socket is still the object, as above. The
fact that the action is taking place on the
receiving machine is grossly inconvinient
from an audit perspective, but otherwise
completely reasonable.

> Then, Does this situation become conflict with what
> you wrote above?

It certainly would be, the way you described it.
The big issue here is one of commonality of
policy (y'all knew I'd get to this somehow)
between the two systems. It is essential that
the attributes that get sent provide the right
sort of information for the receiving machine
to make any and all access control decisions.
Of course, the easiest way to do this is to
ensure that the two machines are using the same
attribute set. The next easiest is to provide a
mechanism for mapping (as TSIG SAMP) the
attribute sets. After that, you're on your own.

An interesting background paper (referenced
in some of the early flux material) on the
topic was presented in 1993. It's good reading
if you can find a copy. I know of no surviving
electronic versions, alas. Oh, and the NSA
evaluation Technical Review Board (TRB) had to
go into conclave for three months to find the
fatal flaw in the paper, which was evident once
the TRB "clarified" their definition of an
object.

  S. Romero, C. Schaufler, and N. Bolyard,
  “BSD IPC model and policy,” in Proc. 16th
  National Computer Security Conference,
  pp. 97106, 1993



Casey Schaufler
casey@schaufler-ca.com


		
__________________________________ 
Discover Yahoo! 
Use Yahoo! to plan a weekend, have fun online and more. Check it out! 
http://discover.yahoo.com/

--
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: Question about integration of IPsec with SELinux?

[Park Lee]

Tue, 14 Jun 2005 at 14:23, Casey Schaufler wrote:
>> Do you mean that attributes of receiving process
>> should be sent to the sending machine, which
>> contains the sending process?
>
> You'd have to anticipate what attributes
> of what objects would be needed before you
> could send packets. Beyond current technology.
> 
>> and the access control
>> are made on the sending machine to decide
>> whether the sending process can do interprocess
>> communication with its receiving process?
>
> Again, if you could get the attributes of all
> the receivers onto the sender in a reliable way
> that would be great.

Do you mean that now we can not achieve this with
current technology?


>> Here, the receiving process becomes
>> subject, and the packets which represent its 
>> sending process become objects. 
>
> Well, not quite. In this scenario the sending
> process is still the subject and the receiving
> socket is still the object, as above. The
> fact that the action is taking place on the
> receiving machine is grossly inconvinient
> from an audit perspective, but otherwise
> completely reasonable.

Here, The receiving socket will receive packets sent
by sending process. So, I think that the receiving
socket is initiative, and the packets are passive on
receiving machine.
Then, Would you please tell me why the sending process
is still the subject and the receiving socket is still
the object?

Thank you very much.

Best Regards,
Park Lee

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

--
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: Question about integration of IPsec with SELinux?

[Casey Schaufler]

--- Park Lee <parklee_sel@yahoo.com> wrote:

> Tue, 14 Jun 2005 at 14:23, Casey Schaufler wrote:
> >> Do you mean that attributes of receiving process
> >> should be sent to the sending machine, which
> >> contains the sending process?
> >
> > You'd have to anticipate what attributes
> > of what objects would be needed before you
> > could send packets. Beyond current technology.
> > 
> >> and the access control
> >> are made on the sending machine to decide
> >> whether the sending process can do interprocess
> >> communication with its receiving process?
> >
> > Again, if you could get the attributes of all
> > the receivers onto the sender in a reliable way
> > that would be great.
> 
> Do you mean that now we can not achieve this with
> current technology?

I mean that the sender cannot know the attributes
that will be present on the receiver at the time
of delivery when the packet is sent. Golly, with
UDP, you don't even know (or care) if the receiver
exists. You can't make the access control decision
on the sender because you don't have enough 
information and the steps that would be required
to get the information and ensure that it didn't
change during the delivery process* would
introduce all sorts of performance and lock
contention issues.

> Here, The receiving socket will receive packets sent
> by sending process. So, I think that the receiving
> socket is initiative, and the packets are passive on
> receiving machine.

A socket is not an active entity. The process
associated with it is, but the process may
never read the information from the socket.
The packets have no volition of their own,
they are the spawn of the sending process.

> Then, Would you please tell me why the sending
> process
> is still the subject and the receiving socket is
> still
> the object?

The sending process puts information into the
receiving socket. The access control decision
is (on Unix MLS systems at least) made based on
the attributes of the socket and the attributes
of the sending process, as propogated to the
receiver via CIPSO or TSIG SAMP.

------
* RFC 1149 has been implemented, after all.



Casey Schaufler
casey@schaufler-ca.com


		
__________________________________ 
Discover Yahoo! 
Get on-the-go sports scores, stock quotes, news and more. Check it out! 
http://discover.yahoo.com/mobile.html

--
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.