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.
Thanks.
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
--
Lukas Vrabec
SELinux Solutions
Red Hat, Inc.
Yes, you are correct it is the same denial before I added the
interfaces, so what do you mean re-create the 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
>
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
--
Lukas Vrabec
SELinux Solutions
Red Hat, Inc.
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
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
>
On 12/13/2015 12: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.
Did you relabel the existing files and directories? Adding a filetrans
will only affect the label of new files/dirs being created.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
On 12/14/2015 03:29 PM, 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
> 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.
Could you attach output of:
$ ls -aZ | grep emacs
It should be something like:
$ ls -aZ | grep emacs
staff_u:object_r:emacs_home_t:s0 .emacs.d
if not, use command restorecon, like:
$ restorecon -R -v .emacs.d # run in your homedir.
I believe .emacs.d has wrong SELinux context.
Could you also show AVC related to this rule:
allow emacs_t user_home_t:file { read write create unlink open lock };
Thank you.
>
> 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
--
Lukas Vrabec
SELinux Solutions
Red Hat, Inc.
-----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-----
Yes I labeled everything correctly, my .emacs.d directory and everything
underneath it is labeled emacs_home_t and I have labeled my emacs binary
with the emacs_exec_t.
On 12/14/2015 09:57 AM, Christopher J. PeBenito wrote:
> On 12/13/2015 12: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.
>
> Did you relabel the existing files and directories? Adding a filetrans
> will only affect the label of new files/dirs being created.
>
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
>
>
-----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-----