[refpolicy] refpolicy interface help

[dac.override@gmail.com (Dominick Grift)]

-----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-----