* [refpolicy] RFC: secure_mode_policyload revision @ 2011-09-23 14:25 Christopher J. PeBenito 2011-09-23 14:53 ` Russell Coker 2011-09-23 15:04 ` Dominick Grift 0 siblings, 2 replies; 9+ messages in thread From: Christopher J. PeBenito @ 2011-09-23 14:25 UTC (permalink / raw) To: refpolicy 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 www.tresys.com | oss.tresys.com ^ permalink raw reply [flat|nested] 9+ messages in thread
* [refpolicy] RFC: secure_mode_policyload revision 2011-09-23 14:25 [refpolicy] RFC: secure_mode_policyload revision Christopher J. PeBenito @ 2011-09-23 14:53 ` Russell Coker 2011-09-23 14:58 ` Daniel J Walsh 2011-09-23 15:04 ` Dominick Grift 1 sibling, 1 reply; 9+ messages in thread From: Russell Coker @ 2011-09-23 14:53 UTC (permalink / raw) To: refpolicy On Sat, 24 Sep 2011, "Christopher J. PeBenito" <cpebenito@tresys.com> 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/ ^ permalink raw reply [flat|nested] 9+ messages in thread
* [refpolicy] RFC: secure_mode_policyload revision 2011-09-23 14:53 ` Russell Coker @ 2011-09-23 14:58 ` Daniel J Walsh 0 siblings, 0 replies; 9+ messages in thread From: Daniel J Walsh @ 2011-09-23 14:58 UTC (permalink / raw) To: refpolicy -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/23/2011 10:53 AM, Russell Coker wrote: > On Sat, 24 Sep 2011, "Christopher J. PeBenito" > <cpebenito@tresys.com> 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----- ^ permalink raw reply [flat|nested] 9+ messages in thread
* [refpolicy] RFC: secure_mode_policyload revision 2011-09-23 14:25 [refpolicy] RFC: secure_mode_policyload revision Christopher J. PeBenito 2011-09-23 14:53 ` Russell Coker @ 2011-09-23 15:04 ` Dominick Grift 2011-09-23 15:43 ` Christopher J. PeBenito 1 sibling, 1 reply; 9+ messages in thread From: Dominick Grift @ 2011-09-23 15:04 UTC (permalink / raw) To: refpolicy 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* [refpolicy] RFC: secure_mode_policyload revision 2011-09-23 15:04 ` Dominick Grift @ 2011-09-23 15:43 ` Christopher J. PeBenito 2011-09-23 16:15 ` Dominick Grift 2011-09-23 16:35 ` Dominick Grift 0 siblings, 2 replies; 9+ messages in thread From: Christopher J. PeBenito @ 2011-09-23 15:43 UTC (permalink / raw) To: refpolicy 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 www.tresys.com | oss.tresys.com ^ permalink raw reply [flat|nested] 9+ messages in thread
* [refpolicy] RFC: secure_mode_policyload revision 2011-09-23 15:43 ` Christopher J. PeBenito @ 2011-09-23 16:15 ` Dominick Grift 2011-09-23 16:35 ` Dominick Grift 1 sibling, 0 replies; 9+ messages in thread From: Dominick Grift @ 2011-09-23 16:15 UTC (permalink / raw) To: refpolicy 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* [refpolicy] RFC: secure_mode_policyload revision 2011-09-23 15:43 ` Christopher J. PeBenito 2011-09-23 16:15 ` Dominick Grift @ 2011-09-23 16:35 ` Dominick Grift 2011-09-23 17:37 ` Daniel J Walsh 1 sibling, 1 reply; 9+ messages in thread From: Dominick Grift @ 2011-09-23 16:35 UTC (permalink / raw) To: refpolicy 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* [refpolicy] RFC: secure_mode_policyload revision 2011-09-23 16:35 ` Dominick Grift @ 2011-09-23 17:37 ` Daniel J Walsh 2011-09-23 18:09 ` Christopher J. PeBenito 0 siblings, 1 reply; 9+ messages in thread From: Daniel J Walsh @ 2011-09-23 17:37 UTC (permalink / raw) To: refpolicy -----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----- ^ permalink raw reply [flat|nested] 9+ messages in thread
* [refpolicy] RFC: secure_mode_policyload revision 2011-09-23 17:37 ` Daniel J Walsh @ 2011-09-23 18:09 ` Christopher J. PeBenito 0 siblings, 0 replies; 9+ messages in thread From: Christopher J. PeBenito @ 2011-09-23 18:09 UTC (permalink / raw) To: refpolicy 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 www.tresys.com | oss.tresys.com ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2011-09-23 18:09 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-09-23 14:25 [refpolicy] RFC: secure_mode_policyload revision Christopher J. PeBenito 2011-09-23 14:53 ` Russell Coker 2011-09-23 14:58 ` Daniel J Walsh 2011-09-23 15:04 ` Dominick Grift 2011-09-23 15:43 ` Christopher J. PeBenito 2011-09-23 16:15 ` Dominick Grift 2011-09-23 16:35 ` Dominick Grift 2011-09-23 17:37 ` Daniel J Walsh 2011-09-23 18:09 ` Christopher J. PeBenito
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.