On Thu, 2011-10-13 at 00:08 +0900, Thu?n ?inh wrote:
> Hi,
>
>
> I'm very strange that the /sbin/init is labeled bin_t
>
>
> The /sbin/init is point to /bin/systemd
>
>
> I check in the /system/init.fc have defiled:
>
>
> /sbin/init(ng)? -- gen_context(system_u:object_r:init_exec_t,s0)
> # because nowadays, /sbin/init is often a symlink to /sbin/upstart
> /sbin/upstart -- gen_context(system_u:object_r:init_exec_t,s0)
>
>
> So, I changed it to:
>
>
> /bin/systemd -- gen_context(system_u:object_r:init_exec_t,s0)
> /sbin/init --
> gen_context(system_u:object_r:init_exec_t,s0)
>
>
> And then, I make, install, load and relabel it again.
>
>
> But after that, the /sbin/init still have labeled bin_t (instead of
> the /bin/systemd is now have init_exec_t)
>
>
> I'm very strange. So, I try to relabel it by command:
>
>
> chcon -t init_exec_t /sbin/init
The /sbin/init symbolic link can be bin_t, no problem.
/sbin/systemd though should be type init_exec_t.
The problem is that reference policy currently does not support systemd.
systemd is not stable yet.
refpolicy is waiting until systemd is stable before she will support it,
because there are too many changes happening to systemd currently.
You could probably, atleast to some extend, work around the issues by
making init a unconfined domain, but that will probably cause issues as
well. So if you are not comfortable with selinux you may want to avoid
that.
?nstead use the policy provided/supported by your distribution instead.
> but it still have labeled sbin_t too.
>
>
> I don't know why and have no ideal.
>
>
> My system is Fedora 15 and using the lasted refpolicy
> I made step by step by this introduction:
> http://oss.tresys.com/projects/refpolicy/wiki/UseRefpolicy
>
>
> Please help me.
>
>
>
> Regard,
> Quang Thuan
>
On Wed, 2011-10-12 at 17:15 +0200, Dominick Grift wrote:
> On Thu, 2011-10-13 at 00:08 +0900, Thu?n ?inh wrote:
> > Hi,
> >
> >
> > I'm very strange that the /sbin/init is labeled bin_t
> >
> >
> > The /sbin/init is point to /bin/systemd
> >
> >
> > I check in the /system/init.fc have defiled:
> >
> >
> > /sbin/init(ng)? -- gen_context(system_u:object_r:init_exec_t,s0)
> > # because nowadays, /sbin/init is often a symlink to /sbin/upstart
> > /sbin/upstart -- gen_context(system_u:object_r:init_exec_t,s0)
> >
> >
> > So, I changed it to:
> >
> >
> > /bin/systemd -- gen_context(system_u:object_r:init_exec_t,s0)
> > /sbin/init --
> > gen_context(system_u:object_r:init_exec_t,s0)
> >
> >
> > And then, I make, install, load and relabel it again.
> >
> >
> > But after that, the /sbin/init still have labeled bin_t (instead of
> > the /bin/systemd is now have init_exec_t)
> >
> >
> > I'm very strange. So, I try to relabel it by command:
> >
> >
> > chcon -t init_exec_t /sbin/init
>
> The /sbin/init symbolic link can be bin_t, no problem.
>
> /sbin/systemd though should be type init_exec_t.
>
> The problem is that reference policy currently does not support systemd.
>
> systemd is not stable yet.
>
> refpolicy is waiting until systemd is stable before she will support it,
> because there are too many changes happening to systemd currently.
>
> You could probably, atleast to some extend, work around the issues by
> making init a unconfined domain, but that will probably cause issues as
> well. So if you are not comfortable with selinux you may want to avoid
> that.
>
> ?nstead use the policy provided/supported by your distribution instead.
Consider Justin Mattock has recently submitted an initial patch (derived
from F15, I suppose) for better supporting systemd in the reference
policy:
18th September 2011
[RFC 1/2]selinux-contrib: add systemd support to refpolicy git
[RFC 2/2] refpolicy: add systemd support to tresys main policy
It's probably worth trying that out (along with the init_systemd
boolean), if it's using systemd...
Regards,
Guido
----- Original Message -----
From: Guido Trentalancia <[email protected]>
To: Dominick Grift <[email protected]>
Cc: refpolicy <[email protected]>
Sent: Wednesday, October 12, 2011 8:39 AM
Subject: Re: [refpolicy] Error when using refpolicy with apache httpd service
On Wed, 2011-10-12 at 17:15 +0200, Dominick Grift wrote:
> On Thu, 2011-10-13 at 00:08 +0900, Thu?n ?inh wrote:
> > Hi,
> >
> >
> > I'm very strange that the /sbin/init is labeled bin_t
> >
> >
> > The /sbin/init is point to /bin/systemd
> >
> >
> > I check in the /system/init.fc have defiled:
> >
> >
> > /sbin/init(ng)? -- gen_context(system_u:object_r:init_exec_t,s0)
> > # because nowadays, /sbin/init is often a symlink to /sbin/upstart
> > /sbin/upstart -- gen_context(system_u:object_r:init_exec_t,s0)
> >
> >
> > So, I changed it to:
> >
> >
> > /bin/systemd? ? -- gen_context(system_u:object_r:init_exec_t,s0)
> > /sbin/init? ? ? ? --
> >? gen_context(system_u:object_r:init_exec_t,s0)
> >
> >
> > And then, I make, install, load and relabel it again.
> >
> >
> > But after that, the /sbin/init still have labeled bin_t (instead of
> > the /bin/systemd is now have init_exec_t)
> >
> >
> > I'm very strange. So, I try to relabel it by command:
> >
> >
> > chcon -t init_exec_t /sbin/init
>
> The /sbin/init symbolic link can be bin_t, no problem.
>
> /sbin/systemd though should be type init_exec_t.
>
> The problem is that reference policy currently does not support systemd.
>
> systemd is not stable yet.
>
> refpolicy is waiting until systemd is stable before she will support it,
> because there are too many changes happening to systemd currently.
>
> You could probably, atleast to some extend, work around the issues by
> making init a unconfined domain, but that will probably cause issues as
> well. So if you are not comfortable with selinux you may want to avoid
> that.
>
> ?nstead use the policy provided/supported by your distribution instead.
Consider Justin Mattock has recently submitted an initial patch (derived
from F15, I suppose) for better supporting systemd in the reference
policy:
18th September 2011
[RFC 1/2]selinux-contrib: add systemd support to refpolicy git
[RFC 2/2] refpolicy: add systemd support to tresys main policy
It's probably worth trying that out (along with the init_systemd
boolean), if it's using systemd...
Regards,
Guido
yeah, anybody have the time to go through that patch set feel free..
last I remember I was hitting some sandbox error for some reason, then ran out of?
time due to external obligations. maybe if the weekend is permitting I can have another go at
it.. as for the patch I pretty much just grepped dans git tree for systemd then copied it to refpolicy,
but there is probably more to it than just grepping.
Justin P. Mattock?
_______________________________________________
refpolicy mailing list
refpolicy at oss.tresys.com
http://oss.tresys.com/mailman/listinfo/refpolicy
----- Original Message -----
From: Justin Mattock <[email protected]>
To: Guido Trentalancia <[email protected]>; Dominick Grift <[email protected]>
Cc: refpolicy <[email protected]>
Sent: Sunday, October 23, 2011 9:25 PM
Subject: Re: [refpolicy] Error when using refpolicy with apache httpd service
----- Original Message -----
From: Guido Trentalancia <[email protected]>
To: Dominick Grift <[email protected]>
Cc: refpolicy <[email protected]>
Sent: Wednesday, October 12, 2011 8:39 AM
Subject: Re: [refpolicy] Error when using refpolicy with apache httpd service
On Wed, 2011-10-12 at 17:15 +0200, Dominick Grift wrote:
> On Thu, 2011-10-13 at 00:08 +0900, Thu?n ?inh wrote:
> > Hi,
> >
> >
> > I'm very strange that the /sbin/init is labeled bin_t
> >
> >
> > The /sbin/init is point to /bin/systemd
> >
> >
> > I check in the /system/init.fc have defiled:
> >
> >
> > /sbin/init(ng)? -- gen_context(system_u:object_r:init_exec_t,s0)
> > # because nowadays, /sbin/init is often a symlink to /sbin/upstart
> > /sbin/upstart -- gen_context(system_u:object_r:init_exec_t,s0)
> >
> >
> > So, I changed it to:
> >
> >
> > /bin/systemd? ?? -- gen_context(system_u:object_r:init_exec_t,s0)
> > /sbin/init? ? ? ? --
> >? gen_context(system_u:object_r:init_exec_t,s0)
> >
> >
> > And then, I make, install, load and relabel it again.
> >
> >
> > But after that, the /sbin/init still have labeled bin_t (instead of
> > the /bin/systemd is now have init_exec_t)
> >
> >
> > I'm very strange. So, I try to relabel it by command:
> >
> >
> > chcon -t init_exec_t /sbin/init
>
> The /sbin/init symbolic link can be bin_t, no problem.
>
> /sbin/systemd though should be type init_exec_t.
>
> The problem is that reference policy currently does not support systemd.
>
> systemd is not stable yet.
>
> refpolicy is waiting until systemd is stable before she will support it,
> because there are too many changes happening to systemd currently.
>
> You could probably, atleast to some extend, work around the issues by
> making init a unconfined domain, but that will probably cause issues as
> well. So if you are not comfortable with selinux you may want to avoid
> that.
>
> ?nstead use the policy provided/supported by your distribution instead.
Consider Justin Mattock has recently submitted an initial patch (derived
from F15, I suppose) for better supporting systemd in the reference
policy:
18th September 2011
[RFC 1/2]selinux-contrib: add systemd support to refpolicy git
[RFC 2/2] refpolicy: add systemd support to tresys main policy
It's probably worth trying that out (along with the init_systemd
boolean), if it's using systemd...
Regards,
Guido
yeah, anybody have the time to go through that patch set feel free..
last I remember I was hitting some sandbox error for some reason, then ran out of?
time due to external obligations. maybe if the weekend is permitting I can have another go at
it.. as for the patch I pretty much just grepped dans git tree for systemd then copied it to refpolicy,
but there is probably more to it than just grepping.
Justin P. Mattock?
doing a google search I am only able to find find the first revision sent for this on the 18th of september.
seems my second revision did not make it through to the list. anyway here is my backup of the two patches..:
http://fpaste.org/FLfg/
http://fpaste.org/5r5t/
I will try and plug this in again over the weekend to see if I can get it running. ?
cheers,
Justin P. Mattock
_______________________________________________
refpolicy mailing list
refpolicy at oss.tresys.com
http://oss.tresys.com/mailman/listinfo/refpolicy
_______________________________________________
refpolicy mailing list
refpolicy at oss.tresys.com
http://oss.tresys.com/mailman/listinfo/refpolicy