<div dir="ltr">Hi Marco,<br><br>On similar lines, as Joe suggested please try with refpolicy 2.20151208 from morty,<br>also I would like to recommend start with refpolicy-minimum policy variant,<br>then you can explore other variants like refpolicy-targeted.<br><br>On Mon, Jul 24, 2017 at 1:15 PM, Marco Ostini <<a href="mailto:marco@ostini.org">marco@ostini.org</a>> wrote:<br>><br>> Hi Joe & Shrikant,<br>><br>> Many thanks for your response. It was good to know that busybox can function with SELinux enforcing enabled.<br>><br>I also confirm busybox works fine with enforcing mode on minimum variant, used it in multiple ways.<br><br>> Sorry not to mention the policy we're currently using. It's:<br>> Â  Â refpolicy-targeted<br>><br>> ||/ Name Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â Version Â  Â  Â  Â  Â  Â  Â Architecture Â  Â  Â  Â  Description<br>> +++-===============================-====================-====================-====================================================================<br>> ii Â refpolicy-targeted Â  Â  Â  Â  Â  Â  Â git-r0 Â  Â  Â  Â  Â  Â  Â  amd64 Â  Â  Â  Â  Â  Â  Â  Â SELinux targeted policy<br>><br>> We'll build policy based on 2.20151208 and give it a try to see how it behaves.<br>><br>> It appears to me that policy itself is responsible for semanage not functioning. When I try:<br>><br>> Â  Â semanage -v port -l<br>><br>> I see errors like this:<br>><br>> 1088. 07/24/17 07:29:46 semanage unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 2 dir write system_u:object_r:lib_t:s0 denied 1095<br>> 1089. 07/24/17 07:29:46 semanage unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 2 dir write system_u:object_r:lib_t:s0 denied 1096<br>><br>> or<br>><br>> time->Mon Jul 24 07:29:46 2017<br>> type=PROCTITLE msg=audit(1500881386.907:1101): proctitle=2F7573722F62696E2F707974686F6E002D4573002F7573722F7362696E2F73656D616E616765002D7600706F7274002D6C<br>> type=SYSCALL msg=audit(1500881386.907:1101): arch=c000003e syscall=2 success=no exit=-13 a0=7ddf20 a1=2c1 a2=81a4 a3=5640003640100 items=0 ppid=496 pid=1201 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="semanage" exe="/usr/bin/python2.7" subj=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 key=(null)<br>> type=AVC msg=audit(1500881386.907:1101): avc: Â denied Â { write } for Â pid=1201 comm="semanage" name="sepolgen" dev="vda" ino=6091 scontext=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 tcontext=system_u:object_r:lib_t:s0 tclass=dir permissive=0<br>><br>> The majority of the errors however are related to start_getty:<br>><br>> 142. 07/24/17 06:14:04 start_getty system_u:system_r:getty_t:s0 4 dir search system_u:object_r:default_t:s0 denied 149<br>><br>> time->Mon Jul 24 07:34:21 2017<br>> type=PROCTITLE msg=audit(1500881661.906:1160): proctitle=2F62696E2F7368002F62696E2F73746172745F676574747900313135323030007474795330<br>> type=SYSCALL msg=audit(1500881661.906:1160): arch=c000003e syscall=59 success=no exit=-13 a0=6fca60 a1=6fcc40 a2=6faf90 a3=59a items=0 ppid=1244 pid=1246 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="start_getty" exe="/bin/bash" subj=system_u:system_r:getty_t:s0 key=(null)<br>> type=AVC msg=audit(1500881661.906:1160): avc: Â denied Â { search } for Â pid=1246 comm="start_getty" name="sbin" dev="vda" ino=7236 scontext=system_u:system_r:getty_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=dir permissive=0<br>><br>> I've applied an appropriate context to start_getty, but that didn't prevent the errors:<br>><br>> ls -alZ /bin/start_getty<br>> -rwxr-xr-x. 1 root root system_u:object_r:getty_exec_t:s0 99 Jul 21 02:55 /bin/start_getty<br>><br>> start_getty is a shell script that points back to /sbin/getty which is a symlink to /usr/lib/busybox/sbin/getty<br>><br>> So I applied a context to Â /usr/lib/busybox/sbin/getty without it preventing the above mentioned errors:<br>><br>> ls -alZ /usr/lib/busybox/sbin/getty<br>> -rwxr-xr-x. 1 root root system_u:object_r:getty_exec_t:s0 21 Jun Â 9 03:39 /usr/lib/busybox/sbin/getty<br>><br><br>I think you are trying to patch the policy Or fixing the avc denials <a href="http://w.r.to">w.r.to</a> context,<br><br>To do it, we have audit tools available from meta-selinux which will help to understand the avc denials in detail,<br>please try using audit2why on avc denials to get why we hit with denials.<br>& further using audit2allow to generate the allow rules based on current policy & then try with generated allow rules.<br><br>Hope it helps :)<br><br>> I'm keen to see how policy based on 2.20151208 will look.<br>><br>> Additional to trying 2.20151208 if you have any suggestions or advice I'd be grateful to hear it.<br>Please start exploring with refpolicy-minimum..<br><br>><br>> Cheers,<br>> Marco<br>><br>><br><br>Thanks<br>Shrikant<br><br>><br>> On 22 July 2017 at 05:46, Joe MacDonald <<a href="mailto:Joe_MacDonald@mentor.com">Joe_MacDonald@mentor.com</a>> wrote:<br>>><br>>> Hi Justin / Marco,<br>>><br>>> [Re: SELinux with Busybox on morty] On 17.07.19 (Wed 16:05) Justin Clacherty wrote:<br>>><br>>> > Hi Joe,<br>>> ><br>>> > Is this something you or one of the other meta-selinux devs are able<br>>> > to help out with or is it more of an upstream question?<br>>><br>>> I'll see if I can give this a shot. Â :-)<br>>><br>>> ><br>>> > Cheers,<br>>> > Justin.<br>>> ><br>>> ><br>>> > > On 17 Jul 2017, at 4:57 pm, Marco Ostini <<a href="mailto:marco@ostini.org">marco@ostini.org</a>> wrote:<br>>> > ><br>>> > ><br>>> > > Hi All,<br>>> > ><br>>> > > At the moment I'm attempting to prepare a VM of morty with SELinux<br>>> > > running well in enforcing mode. Once bedded down this will be<br>>> > > running on an embedded system.<br>>> > ><br>>> > > We use Busybox to keep the environment slim.<br>>> > ><br>>> > > As you may be aware the file contexts of<br>>> > > /etc/selinux/targeted/contexts/files/file_contexts don't include<br>>> > > appropriate paths (/sbin + /usr/lib/busybox/sbin/) and relative file<br>>> > > contexts for commands provided by Busybox. The /sbin files provided<br>>> > > by Busybox are symlinks to their counterparts in<br>>> > > /usr/lib/busybox/sbin/.<br>>> > ><br>>> > > I've attempted to use semanage to apply file contexts and look up<br>>> > > login contexts. Any time I use semanage I receive this message:<br>>> > ><br>>> > > Â  Â Error: Failed to read //etc/selinux/targeted/policy/policy.30 policy file<br>>> > ><br>>> > > In an attempt to mitigate this error I ran semodule --build and<br>>> > > while it did rebuild the policy file, it didn't mitigate the error<br>>> > > message generated by semanage. At the moment I'm applying temporary<br>>> > > file contexts with chcon.<br>>> > ><br>>> > > My questions are:<br>>> > ><br>>> > > 1. Is it possible to run Busybox (providing init, getty, syslog ...)<br>>> > > in SELinux enforcing. If so, where's the policy files?<br>>><br>>> You haven't mentioned which policy you're currently using so I'm<br>>> guessing it is the default you get from meta-selinux, that is<br>>> refpolicy-git.  I've been debugging some (I think) unrelated issues with<br>>> refpolicy-git this week, so my advice would first to be try out<br>>> 2.20151208, the current release version we have in tree.  That's<br>>> obviously also out of date, but it is currently better tested than the<br>>> git recipe.<br>>><br>>> All that said, yes, we have been, in the past, able to use busybox with<br>>> SELinux enforcing enabled, though as you can see from the layer, we've<br>>> had to tweak refpolicy to make it work well.  I'm adding a colleague of<br>>> mine here, Shrikant, who has done a fair bit of recent work with<br>>> meta-selinux as well, he might have some additional insight into the<br>>> current status of busybox-based systems.<br>>><br>>> > > 2. Is there some documentation somewhere on reference builds of<br>>> > > Morty with SELinux enforcing ?<br>>><br>>> There is not at the moment, as far as I know.  It's possible that<br>>> someone else currently using that combination can help out with some<br>>> guidance, but we haven't done any Morty+SELinux specific documentation.<br>>> Since I'm investigating some other issues right now in a slightly<br>>> different area, though, I may get some time next week to write up<br>>> something quick for this for you, though. If I do, I'll be sure to share<br>>> it here.<br>>><br>>> --<br>>> -Joe MacDonald.<br>>> :wq<br>><br>><br>><br>> --<br>> _______________________________________________<br>> yocto mailing list<br>> <a href="mailto:yocto@yoctoproject.org">yocto@yoctoproject.org</a><br>> <a href="https://lists.yoctoproject.org/listinfo/yocto">https://lists.yoctoproject.org/listinfo/yocto</a><br>></div>