From: dac.override@gmail.com (Dominick Grift) Date: Sat, 19 Dec 2015 11:24:37 +0100 Subject: [refpolicy] refpolicy interface help In-Reply-To: <566F86EA.3080809@yahoo.com> References: <566D0441.8060600@yahoo.com> <566D7265.6070100@redhat.com> <566DED98.4010907@yahoo.com> <566EAE27.6070009@redhat.com> <566ED240.8050009@yahoo.com> <20151214151749.GA12401@x250> <566F86EA.3080809@yahoo.com> Message-ID: <20151219102436.GA302@x250> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Mon, Dec 14, 2015 at 10:20:10PM -0500, Dan wrote: > Yeah I probably shouldn't have tried to confine something like emacs off > the bat but I have written over 20 policy modules so I thought it > wouldn't be too bad. I will have a look at your emacs policy module and > I am starting to learn cil so I might understand some of it. Anyways > here is my policy: > > http://paste.fedoraproject.org/300888/45014865/ Sorry for late reply. Your address is flagged as spam by google for some reason, and i overlooked it. I am not familiar with Fedora policy but in theory you shouldnt be seeing the "allow emacs_t user_home_t:file create;", so see if you can reproduce that event. Because as stated there is a rule that say's let emacs_t create any file in user_home_t type dirs with a type transition. I would probably use sesearch to see what "raw" rules are in place since that is what eventually matters. hth > > > And I don't expect emacs to work with what I have already have in > enforcing mode. I was just confused on the interfaces I used. I guess my > biggest thing is trying to figure out what needs access to what because > I am the type of person that wants everything pretty much locked down > with no room to breathe. > > > > > > > > > > > > On 12/14/2015 10:17 AM, Dominick Grift wrote: > > 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 > > > > > _______________________________________________ > 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 iQGcBAEBCgAGBQJWdTBfAAoJENAR6kfG5xmcYSML/A9IqwzzzaGCyCI9FYHgadLB PSonrHHgQ1N+6ix6bSC43JP7i8QaBt+9PkEcBSEm49bjsGWFxWmgtTIFfAS6QUBg GL6FAmPsOfePgyH5KPgOfjEP/0vQmwqHk5EpPU7b+h7cMHHrt/5YLVzgmreUdjMd HdCFTFXRbQASbml5cEnLzvjel++2oZ5X9w+Hm/QGbGSbRpM/RapYLLeA5tFgFHaD yvvxmtsuG3NByeREVz1+Bg73kgQ8io58RqN5aTblKw81KvVQPx5UcpPu9Cn0deEe 60mg0lY2jDCK92TBL0bZYN32H0r3XlcjO69ep/anHFAtQ6cYBMMRr8kKnHYR5ned sF2Qqdj/VhkWALHSrQTIlXnSRviZ3d53kYbKC8LHrcwYusWymS1TOuG+hEol1pn/ 8lOur3o+ZK5XewQWDNJfvdKEM9Z7jgtmDOMLgdmq2hlEixXHBu9I/CJ4UMZ++yCi 2CiDVwLsx4Znbm/5duokbW6qXLADDUxnuzrSImM8lQ== =1p31 -----END PGP SIGNATURE-----