Right now, secure_mode_policyload disables policy loading and Boolean changing. The latter is to prevent secure_mode_policyload from being turned off. I was thinking that secure_mode_policyload could be revised by labeling this Boolean, and then only removing access to it when secure_mode_policyload is enabled, so Booleans can still be toggled, except for secure_mode_policyload. Thoughts?
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
On Sat, 24 Sep 2011, "Christopher J. PeBenito" <[email protected]> wrote:
> Right now, secure_mode_policyload disables policy loading and Boolean
> changing. The latter is to prevent secure_mode_policyload from being
> turned off. I was thinking that secure_mode_policyload could be revised
> by labeling this Boolean, and then only removing access to it when
> secure_mode_policyload is enabled, so Booleans can still be toggled,
> except for secure_mode_policyload. Thoughts?
Sounds good.
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 09/23/2011 10:53 AM, Russell Coker wrote:
> On Sat, 24 Sep 2011, "Christopher J. PeBenito"
> <[email protected]> wrote:
>> Right now, secure_mode_policyload disables policy loading and
>> Boolean changing. The latter is to prevent
>> secure_mode_policyload from being turned off. I was thinking
>> that secure_mode_policyload could be revised by labeling this
>> Boolean, and then only removing access to it when
>> secure_mode_policyload is enabled, so Booleans can still be
>> toggled, except for secure_mode_policyload. Thoughts?
>
> Sounds good.
>
Sure.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk58nokACgkQrlYvE4MpobPYZACg68KdErKNdgkIt4W0NBMzBO+q
pXwAnR4leqZ69Dqn8jsMQV+Hb6ozvMWc
=26/K
-----END PGP SIGNATURE-----
On Fri, 2011-09-23 at 10:25 -0400, Christopher J. PeBenito wrote:
> Right now, secure_mode_policyload disables policy loading and Boolean changing. The latter is to prevent secure_mode_policyload from being turned off. I was thinking that secure_mode_policyload could be revised by labeling this Boolean, and then only removing access to it when secure_mode_policyload is enabled, so Booleans can still be toggled, except for secure_mode_policyload. Thoughts?
>
My thoughts on this are:
Does boolean toggling not involve a policyload? ( I am too lazy to add a
auditallow rule, but i gather you took that into account so must not be
the case or policyload must actually not refer to load_policy permission
)
> Sep 23 16:58:10 x220 dbus[1511]: avc: received policyload notice (seqno=2)
> Sep 23 16:58:10 x220 dbus[1138]: avc: received policyload notice (seqno=2)
> Sep 23 16:58:10 x220 dbus-daemon[1138]: dbus[1138]: avc: received policyload notice (seqno=2)
> Sep 23 16:58:10 x220 dbus[1138]: [system] Reloaded configuration
> Sep 23 16:58:10 x220 dbus-daemon[1138]: dbus[1138]: [system] Reloaded configuration
> Sep 23 16:58:10 x220 setsebool: The xend_run_qemu policy boolean was changed to on by root
Besides that i think:
> ## <desc>
> ## <p>
> ## Make the specified type used for labeling SELinux Booleans.
> ## </p>
> ## <p>
> ## This makes use of genfscon statements, which are only
> ## available in the base module. Thus any module which calls this
> ## interface must be included in the base module.
> ## </p>
> ## </desc>
No big deal in this case because selinux module is in base already.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110923/cc53af8f/attachment.bin
On 09/23/11 11:04, Dominick Grift wrote:
> On Fri, 2011-09-23 at 10:25 -0400, Christopher J. PeBenito wrote:
>> Right now, secure_mode_policyload disables policy loading and Boolean changing. The latter is to prevent secure_mode_policyload from being turned off. I was thinking that secure_mode_policyload could be revised by labeling this Boolean, and then only removing access to it when secure_mode_policyload is enabled, so Booleans can still be toggled, except for secure_mode_policyload. Thoughts?
>>
>
> My thoughts on this are:
>
> Does boolean toggling not involve a policyload? ( I am too lazy to add a
> auditallow rule, but i gather you took that into account so must not be
> the case or policyload must actually not refer to load_policy permission
> )
>
>> Sep 23 16:58:10 x220 dbus[1511]: avc: received policyload notice (seqno=2)
>> Sep 23 16:58:10 x220 dbus[1138]: avc: received policyload notice (seqno=2)
>> Sep 23 16:58:10 x220 dbus-daemon[1138]: dbus[1138]: avc: received policyload notice (seqno=2)
>> Sep 23 16:58:10 x220 dbus[1138]: [system] Reloaded configuration
>> Sep 23 16:58:10 x220 dbus-daemon[1138]: dbus[1138]: [system] Reloaded configuration
>> Sep 23 16:58:10 x220 setsebool: The xend_run_qemu policy boolean was changed to on by root
Are you sure you're not doing setsebool -P? That rebuilds the policy. If you skip -P, it shouldn't require a policy load. If it is triggering a policy load, that is a bug.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
On Fri, 2011-09-23 at 11:43 -0400, Christopher J. PeBenito wrote:
> On 09/23/11 11:04, Dominick Grift wrote:
> > On Fri, 2011-09-23 at 10:25 -0400, Christopher J. PeBenito wrote:
> >> Right now, secure_mode_policyload disables policy loading and Boolean changing. The latter is to prevent secure_mode_policyload from being turned off. I was thinking that secure_mode_policyload could be revised by labeling this Boolean, and then only removing access to it when secure_mode_policyload is enabled, so Booleans can still be toggled, except for secure_mode_policyload. Thoughts?
> >>
> >
> > My thoughts on this are:
> >
> > Does boolean toggling not involve a policyload? ( I am too lazy to add a
> > auditallow rule, but i gather you took that into account so must not be
> > the case or policyload must actually not refer to load_policy permission
> > )
> >
> >> Sep 23 16:58:10 x220 dbus[1511]: avc: received policyload notice (seqno=2)
> >> Sep 23 16:58:10 x220 dbus[1138]: avc: received policyload notice (seqno=2)
> >> Sep 23 16:58:10 x220 dbus-daemon[1138]: dbus[1138]: avc: received policyload notice (seqno=2)
> >> Sep 23 16:58:10 x220 dbus[1138]: [system] Reloaded configuration
> >> Sep 23 16:58:10 x220 dbus-daemon[1138]: dbus[1138]: [system] Reloaded configuration
> >> Sep 23 16:58:10 x220 setsebool: The xend_run_qemu policy boolean was changed to on by root
>
> Are you sure you're not doing setsebool -P? That rebuilds the policy. If you skip -P, it shouldn't require a policy load. If it is triggering a policy load, that is a bug.
>
Erm yes i am using -P how does that affect my argument?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110923/1d026961/attachment.bin
On Fri, 2011-09-23 at 11:43 -0400, Christopher J. PeBenito wrote:
> On 09/23/11 11:04, Dominick Grift wrote:
> > On Fri, 2011-09-23 at 10:25 -0400, Christopher J. PeBenito wrote:
> >> Right now, secure_mode_policyload disables policy loading and Boolean changing. The latter is to prevent secure_mode_policyload from being turned off. I was thinking that secure_mode_policyload could be revised by labeling this Boolean, and then only removing access to it when secure_mode_policyload is enabled, so Booleans can still be toggled, except for secure_mode_policyload. Thoughts?
> >>
> >
> > My thoughts on this are:
> >
> > Does boolean toggling not involve a policyload? ( I am too lazy to add a
> > auditallow rule, but i gather you took that into account so must not be
> > the case or policyload must actually not refer to load_policy permission
> > )
> >
> >> Sep 23 16:58:10 x220 dbus[1511]: avc: received policyload notice (seqno=2)
> >> Sep 23 16:58:10 x220 dbus[1138]: avc: received policyload notice (seqno=2)
> >> Sep 23 16:58:10 x220 dbus-daemon[1138]: dbus[1138]: avc: received policyload notice (seqno=2)
> >> Sep 23 16:58:10 x220 dbus[1138]: [system] Reloaded configuration
> >> Sep 23 16:58:10 x220 dbus-daemon[1138]: dbus[1138]: [system] Reloaded configuration
> >> Sep 23 16:58:10 x220 setsebool: The xend_run_qemu policy boolean was changed to on by root
>
> Are you sure you're not doing setsebool -P? That rebuilds the policy. If you skip -P, it shouldn't require a policy load. If it is triggering a policy load, that is a bug.
>
I guess you are saying that booleans without -P can be toggled but not
with -P.
I cannot remember the last time i used setsebool without -P, but ok.
Pretty insignificant change in my view. Might be confusing for a sysadm
but then again, if one uses that boolean one is probably familiar with
SELinux.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110923/8bfd62da/attachment.bin
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 09/23/2011 12:35 PM, Dominick Grift wrote:
> On Fri, 2011-09-23 at 11:43 -0400, Christopher J. PeBenito wrote:
>> On 09/23/11 11:04, Dominick Grift wrote:
>>> On Fri, 2011-09-23 at 10:25 -0400, Christopher J. PeBenito
>>> wrote:
>>>> Right now, secure_mode_policyload disables policy loading and
>>>> Boolean changing. The latter is to prevent
>>>> secure_mode_policyload from being turned off. I was thinking
>>>> that secure_mode_policyload could be revised by labeling this
>>>> Boolean, and then only removing access to it when
>>>> secure_mode_policyload is enabled, so Booleans can still be
>>>> toggled, except for secure_mode_policyload. Thoughts?
>>>>
>>>
>>> My thoughts on this are:
>>>
>>> Does boolean toggling not involve a policyload? ( I am too lazy
>>> to add a auditallow rule, but i gather you took that into
>>> account so must not be the case or policyload must actually not
>>> refer to load_policy permission )
>>>
>>>> Sep 23 16:58:10 x220 dbus[1511]: avc: received policyload
>>>> notice (seqno=2) Sep 23 16:58:10 x220 dbus[1138]: avc:
>>>> received policyload notice (seqno=2) Sep 23 16:58:10 x220
>>>> dbus-daemon[1138]: dbus[1138]: avc: received policyload
>>>> notice (seqno=2) Sep 23 16:58:10 x220 dbus[1138]: [system]
>>>> Reloaded configuration Sep 23 16:58:10 x220
>>>> dbus-daemon[1138]: dbus[1138]: [system] Reloaded
>>>> configuration Sep 23 16:58:10 x220 setsebool: The
>>>> xend_run_qemu policy boolean was changed to on by root
>>
>> Are you sure you're not doing setsebool -P? That rebuilds the
>> policy. If you skip -P, it shouldn't require a policy load. If
>> it is triggering a policy load, that is a bug.
>>
>
> I guess you are saying that booleans without -P can be toggled but
> not with -P.
>
> I cannot remember the last time i used setsebool without -P, but
> ok.
>
> Pretty insignificant change in my view. Might be confusing for a
> sysadm but then again, if one uses that boolean one is probably
> familiar with SELinux.
>
>
>
> _______________________________________________ refpolicy mailing
> list refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
We might be eventually moving to tunables/booleans which will drop the
number of booleans to about 4. Perhaps making this change mute.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk58w+QACgkQrlYvE4MpobOlpgCgvOFWqUr38WIH05f/37WU1jeV
kLoAni2niq/5eLBHpP3cZqfazGSMuMx+
=/Ibz
-----END PGP SIGNATURE-----
On 9/23/2011 1:37 PM, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 09/23/2011 12:35 PM, Dominick Grift wrote:
>> On Fri, 2011-09-23 at 11:43 -0400, Christopher J. PeBenito wrote:
>>> On 09/23/11 11:04, Dominick Grift wrote:
>>>> On Fri, 2011-09-23 at 10:25 -0400, Christopher J. PeBenito
>>>> wrote:
>>>>> Right now, secure_mode_policyload disables policy loading and
>>>>> Boolean changing. The latter is to prevent
>>>>> secure_mode_policyload from being turned off. I was thinking
>>>>> that secure_mode_policyload could be revised by labeling this
>>>>> Boolean, and then only removing access to it when
>>>>> secure_mode_policyload is enabled, so Booleans can still be
>>>>> toggled, except for secure_mode_policyload. Thoughts?
>>>>>
>>>>
>>>> My thoughts on this are:
>>>>
>>>> Does boolean toggling not involve a policyload? ( I am too lazy
>>>> to add a auditallow rule, but i gather you took that into
>>>> account so must not be the case or policyload must actually not
>>>> refer to load_policy permission )
>>>>
>>>>> Sep 23 16:58:10 x220 dbus[1511]: avc: received policyload
>>>>> notice (seqno=2) Sep 23 16:58:10 x220 dbus[1138]: avc:
>>>>> received policyload notice (seqno=2) Sep 23 16:58:10 x220
>>>>> dbus-daemon[1138]: dbus[1138]: avc: received policyload
>>>>> notice (seqno=2) Sep 23 16:58:10 x220 dbus[1138]: [system]
>>>>> Reloaded configuration Sep 23 16:58:10 x220
>>>>> dbus-daemon[1138]: dbus[1138]: [system] Reloaded
>>>>> configuration Sep 23 16:58:10 x220 setsebool: The
>>>>> xend_run_qemu policy boolean was changed to on by root
>>>
>>> Are you sure you're not doing setsebool -P? That rebuilds the
>>> policy. If you skip -P, it shouldn't require a policy load. If
>>> it is triggering a policy load, that is a bug.
>>>
>>
>> I guess you are saying that booleans without -P can be toggled but
>> not with -P.
>>
>> I cannot remember the last time i used setsebool without -P, but
>> ok.
Precisely why I always pushed for real tunables. Booleans were supposed to be more transient.
>> Pretty insignificant change in my view. Might be confusing for a
>> sysadm but then again, if one uses that boolean one is probably
>> familiar with SELinux.
>
> We might be eventually moving to tunables/booleans which will drop the
> number of booleans to about 4. Perhaps making this change mute.
Actually, I was thinking about this in a pure functionality sense, not as a policy size optimization.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com