Matt Harrison wrote: > max wrote: >> Matt Harrison wrote: >>> max wrote: >>>> Matt Harrison wrote: >>>>> Matt Harrison wrote: >>>>>> I previously installed a virtual machine with selinux etc to see if I >>>>>> could get my head round it and it all worked fine. >>>>> Actually this isn't true, when enabling enforce on my test machine it >>>>> locks me out of everything as well. >>>>> >>>>> This is a complete mystery to me and quite disappointing. >>>>> >>>> set selinux to permissive and check the logs when the box comes up >>>> >>> Thanks for the reply, >>> >>> Ok, firstly if I boot up in enforcing mode it halts saying something >>> like access to /sbin/init was denied. >>> >>> If I boot up permissive I get tonnes of denied messages in dmesg. >>> There's far too many to list so I've attached a trimmed dmesg output, >>> starting from the first related message. >>> >>> From my untrained eye looking over these messages it seems that a lot of >>> core system stuff is being denied access, why I have no clue, everything >>> should be labelled and setup according to the gentoo selinux howto. >>> >>> Grateful for any input. >>> >>> Thanks >>> >>> Matt >> Do you happen to have the build.conf file for your policy? I am still >> working on building my gentoo box, i mainly run fedora but I notice >> that, at least on Fedora, the following is set to allow(From your dmesg): >> >> security: class peer not defined in policy >> security: class capability2 not defined in policy >> security: permission recvfrom in class node not defined in policy >> security: permission sendto in class node not defined in policy >> security: permission ingress in class netif not defined in policy >> security: permission egress in class netif not defined in policy >> security: permission setfcap in class capability not defined in policy >> security: permission flow_in in class packet not defined in policy >> security: permission flow_out in class packet not defined in policy >> security: permission forward_in in class packet not defined in policy >> security: permission forward_out in class packet not defined in policy >> SELinux: Completing initialization. >> SELinux: Setting up existing superblocks. >> >> SELinux: policy loaded with handle_unknown=deny >> >> If i compile a policy on Fedora this is always set to allow, if not I >> usually run into problems like your having, I don't know enough about >> gentoo to know if this is supposed to be this way here or not, perhaps >> someone else can supply the answer. The description in the build.conf file: >>> # Unknown Permissions Handling >>> # The behavior for handling permissions defined in the >>> # kernel but missing from the policy. The permissions >>> # can either be allowed, denied, or the policy loading >>> # can be rejected. >>> # allow, deny, and reject are current options. >> You could try recompiling the policy with this set to allow, that, i >> think, should resolve the issue for you but I don't really know how >> different the default fedora and gentoo policies are so take it with a >> grain of salt. Aside from that I could only suggest running the denials >> through audit to allow2allow but I think changing that option there is >> your best bet. Your showing quite a few things not defined in policy and >> they are getting denied. >> >> UNK_PERMS=allow >> >> >> -Max >> > > This is a totally standard policy, I haven't modified anything since the > emerges. Since I haven't modified anything I'm not sure where to find > the build.conf. Where might I be able to find it? > > Thanks > > Matt >
Scratch that I've found it at /usr/share/selinux/strict/include/build.conf. See attached thanks Matt
TYPE ?= strict NAME ?= strict DISTRO ?= gentoo MONOLITHIC ?= n DIRECT_INITRC ?= n override MLS_SENS := 16 override MLS_CATS := 256 override MCS_CATS := 256
