30.07.2012 09:30, Andrew Beekhof wrote: > On Mon, Jul 30, 2012 at 2:21 PM, Vladislav Bogdanov > <bub...@hoster-ok.com> wrote: >> 30.07.2012 02:39, Andrew Beekhof wrote: >>> On Tue, Jul 24, 2012 at 2:25 PM, Vladislav Bogdanov >>> <bub...@hoster-ok.com> wrote: >>>> 24.07.2012 04:50, Andrew Beekhof wrote: >>>>> On Tue, Jul 24, 2012 at 5:38 AM, David Barchas <d...@barchas.com> wrote: >>>>>> >>>>>> On Monday, July 23, 2012 at 7:48 AM, David Barchas wrote: >>>>>> >>>>>> >>>>>> Date: Mon, 23 Jul 2012 14:15:27 +0300 >>>>>> From: Vladislav Bogdanov >>>>>> >>>>>> 23.07.2012 08:06, David Barchas wrote: >>>>>> >>>>>> Hello. >>>>>> >>>>>> I have been working on this for 3 days now, and must be so stressed out >>>>>> that I am being blinded to what is probably an obvious cause of this. In >>>>>> a word, HELP. >>>>>> >>>>>> >>>>>> setenforce 0 ? >>>>>> >>>>>> i am familiar with it but have never had to disable it. I would be >>>>>> surprised >>>>>> for packages in standard repos. >>>>> >>>>> No-one has written an selinux policy for pacemaker yet. >>>>> I would imagine that will come in the next month or so. >>>>> >>>> >>>> Highly appreciated. However lrmd part may be not as easy to implement >>>> properly as it seems at the first glance. >>>> >>> >>> You basically have to let the lrmd run unconfined. >>> I don't think there is any sensible way to constraint something that, >>> by design, needs to be able to perform arbitrary actions as root. >>> To do otherwise you would need to enumerate every possible service + >>> agent that anyone would ever want to write. >> >> Will it (kernel and policy engine) make transition from unconfined_t to >> appropriate selinux roles when services are stared? > > > One would hope so, I don't have enough selinux knowledge to know for sure.
I suspect it should (if unconfined_t is not blocked). At least starting system daemons from a root shell (which runs as unconfined_t at my system) results in proper label on a daemon process (the only difference is a selinux user part - unconfined_u instead of system_u). One other option (which should work even in fully-confined setups) would be to bind lrmd to init_t role (mark it as system_u:object_r:init_exec_t:s0), so /sbin/init and lrmd do not differ from selinux PoV. That would be close to the reality - their functions are very simalar to each other - they both manage the system. That would probably require to extend init_t permissions, so that role can run OCF scripts (can be solved with proper *initrc_exec_t labels on them) and communicate with the rest of pacemaker. Whether that additional rules are allowed or not may be controlled by a selinux variable. One more extension to that role would be to allow operations with HA_RSCTMP (if scripts inherit init_t role from lrmd - which is probably sane enough), But even then, some OCF scripts would probably require special labeling (just like some of initrc scripts - while the majority is marked as system_u:object_r:initrc_exec_t:s0, some scripts has dedicated roles, like system_u:object_r:iptables_initrc_exec_t:s0). That is a (right/more secure) way to go I think, but that is of course much more complicated than just running lrmd unconfined. Vladislav _______________________________________________ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
