RE: Brindle example of labeled IPSec

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Sorry. I forgot to include the policy version in my original response.
See below

> -----Original Message-----
> From: Clarkson, Mike R (US SSA)
> Sent: Friday, February 15, 2008 3:48 PM
> To: 'Paul Moore'
> Cc: selinux@xxxxxxxxxxxxx
> Subject: RE: Brindle example of labeled IPSec
> 
> 
> 
> > -----Original Message-----
> > From: Paul Moore [mailto:paul.moore@xxxxxx]
> > Sent: Friday, February 15, 2008 3:43 PM
> > To: Clarkson, Mike R (US SSA)
> > Cc: selinux@xxxxxxxxxxxxx
> > Subject: Re: Brindle example of labeled IPSec
> >
> > On Friday 15 February 2008 6:25:45 pm Clarkson, Mike R (US SSA)
wrote:
> > > I understand why there is no labeling after doing "setkey -FP".
That
> > > was expected.
> >
> > I'm sorry, I mis-read your original question.
> >
> > > My question is why does the labeling work in enforcing mode, even
> > > though my policy does not provide the following rules:
> > > allow brindle_client_t ipsec_spd_t:association polmatch;
> > > allow brindle_client_t brindle_server_t:association recvfrom;
> > >
> > > With labeled IPSec over the loopback, I did not have to provide
any
> > > rules in my brindle_client module or my brindle_server module with
> > > respect to the association object class. Without the association
> > > rules, the policy doesn't have any way of enforcing MLS
constraints,
> > > or TE on the client server connections, which is the reason that I
> > > set up labeled IPSec over loopback in the first place.
> >
> > That is interesting isn't it?  I don't have an answer off the top of
my
> > head which means I need to go and dig through the kernel and policy
to
> > try and piece together what is going on.  What kernel version and
> > policy version are you running?
> 
> Kernel: 2.6.18-53.el5 (x86_64)
> Policy: RHEL5.1

Policy Version & Type: v.21 (binary, MLS)

> 
> Thanks
> 
> >
> > --
> > paul moore
> > linux security @ hp



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

[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux