[refpolicy] refpolicy interface help

[dtdevore64@yahoo.com (Dan)]

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/


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