From: dac.override@gmail.com (Dominick Grift) Date: Mon, 14 Dec 2015 16:17:50 +0100 Subject: [refpolicy] refpolicy interface help In-Reply-To: <566ED240.8050009@yahoo.com> References: <566D0441.8060600@yahoo.com> <566D7265.6070100@redhat.com> <566DED98.4010907@yahoo.com> <566EAE27.6070009@redhat.com> <566ED240.8050009@yahoo.com> Message-ID: <20151214151749.GA12401@x250> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Mon, Dec 14, 2015 at 09:29:20AM -0500, Dan wrote: > Yes I am basically using audit2allow like this: > > sudo ausearch -m avc -ts 20:18 | audit2allow -r > > As for the AVCs, here they are: > > allow emacs_t user_home_t:file { read write create unlink open lock }; > allow emacs_t config_home_t:file { read write getattr open }; > allow emacs_t ssh_exec_t:file execute > allow emacs_t gpg_exec_t:file { execute getattr }; > > I mean am I wrong to think that allowing emacs to write to any type that > is labeled user_home_t, or should I just allow because it seems my > interfaces aren't working with the transition. Basically what it comes The type transition should just work, you are overlooking something. You should have picked an easier application to become familiar with writing SELinux policy. It may (or may not) help if we can have a look at your policy. Emacs is a pretty complex application. For example there are actually two processes the server and the client. Also in the bigger picture you probably want emacs to be able to manage user_home_t content becuase that is generally sharable. You want to be able to for example use emacs to edit your git repositories and or you may want to use emacs as an editor for your mail client (for example mutt) Also you probably want to prefix emacs so that you can tell selinux that emacs should execute shells, git, gpg etc on your behalf. Eventually you want to be able to use emacs as you would normally. I Have emacs confined but the policy is not written in refpolicy but instead cil. Not sure if it is a good idea to reference that here since it may only add to the confusion: https://github.com/DefenSec/dssp-contrib/tree/master/applications/emacs https://github.com/DefenSec/dssp-contrib/tree/master/applications/emacsclient https://github.com/DefenSec/dssp-contrib/tree/master/roles/user_emacs https://github.com/DefenSec/dssp-contrib/tree/master/roles/user_emacsclient > down to is if I confine any application with selinux what rule, > interface,macro do I need to use so I won't get any AVCs about that > application writing to my user_home_t type. That is pretty much what I > want to know. Thanks for helping me out. > > On 12/14/2015 06:55 AM, Lukas Vrabec wrote: > > > > > > On 12/13/2015 11:13 PM, Dan wrote: > >> Yes, you are correct it is the same denial before I added the > >> interfaces, so what do you mean re-create the AVC messages? > > Could you attach how you exactly using "audit2allow" command and also > > AVC messages? > >> On 12/13/2015 08:28 AM, Lukas Vrabec wrote: > >>> HI, > >>> > >>> On 12/13/2015 06:38 AM, Dan wrote: > >>>> Hello all, I am confining the application emacs using the selinux > >>>> refpolicy and I seem to be stuck on one little part. I get this one > >>>> audit2allow rule that says allow emacs_t user_home_t:file { rename > >>>> write > >>>> create read open }; > >>>> > >>>> Now my problem with that rule is that I don't want my application to > >>>> write or create files with the user_home_t, so I decided to use an > >>>> interface. The interfaces I used are these below: > >>>> > >>>> userdom_user_home_dir_filetrans(emacs_t, emacs_home_t, dir, ".emacs.d") > >>>> > >>>> userdom_user_home_content_filetrans(emacs_t, emacs_home_t, { file dir > >>>> lnk_file }) > >>>> > >>>> > >>>> > >>>> But the problem is when I added these into my policy and when trying to > >>>> to an audit2allow on the most recent time and date the denial was still > >>>> there for some odd reason and I don't know what interface, macro, or > >>>> whatever to use to get rid of the denial allow emacs_t user_home_t:file > >>>> { rename write create read open }; Any help would be much appreciated. > >>> If I understand this correctly, you are using audit2allow on the same > >>> AVC msg, that you used before adding interface? If yes, this is correct > >>> audit2allow behavior, because in AVC msg is target context user_home_t > >>> not emacs_home_t. So you need to re-create AVC msgs. > >>> > >>> Regards, > >>> Lukas Vrabec. > >>>> Thanks. > >>>> _______________________________________________ > >>>> refpolicy mailing list > >>>> refpolicy at oss.tresys.com > >>>> http://oss.tresys.com/mailman/listinfo/refpolicy > > > _______________________________________________ > refpolicy mailing list > refpolicy at oss.tresys.com > http://oss.tresys.com/mailman/listinfo/refpolicy - -- 02DFF788 4D30 903A 1CF3 B756 FB48 1514 3148 83A2 02DF F788 https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788 Dominick Grift -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGcBAEBCgAGBQJWbt2ZAAoJENAR6kfG5xmcuUAMANTzleeQYFuYL5LXtbdik9R1 aipF2KEqIDHHekE/qsj+tRkwwtM6RBLAel7nfujFXCIzhUavb5wdnImKfuwfJ9bQ OX26OB3RGtuL9zdVURGyXNEsmvrUUi/luU+bDv4dAjdSxKna0WYzR2Mr7ah8BvYc XDtLIw+LvrKnr4Fi5ciaWDphRdFNWPDYjBv6jm5MaR4f7FLGJbwQLWojARZ0u+7y PhnWgMAtIEjv9ecfD5HNTEEPTp9cESGPJQbNpAvX1oseabdduxUizhgYarCIJRqn gvrr8VHsGMDZxotqhnVqu0+ArKLSdzuvqR4ZrNUnTs4MP/YmjmIyglJcAWYsurPj Z+bRAcj+OrgBKX3y2FSiGEukcydqwKgO6cDz/muHjQ3kkvFes0BgBGAhIIac262q FnoWyMvfIMG9wzkKenSoCk+NJEv2v/jrl7Aesz6kXx25mWkyoEcgn2IU/cFHWDGm fw+xJ4h7/HR5sjU6Tyr0YL8YJr/s85ZC9CtHI+BUng== =7W0a -----END PGP SIGNATURE-----