From: lvrabec@redhat.com (Lukas Vrabec)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] refpolicy interface help
Date: Mon, 14 Dec 2015 16:00:28 +0100 [thread overview]
Message-ID: <566ED98C.6010508@redhat.com> (raw)
In-Reply-To: <566ED240.8050009@yahoo.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.
next prev parent reply other threads:[~2015-12-14 15:00 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-13 5:38 [refpolicy] refpolicy interface help Dan
2015-12-13 13:28 ` Lukas Vrabec
2015-12-13 22:13 ` Dan
2015-12-14 11:55 ` Lukas Vrabec
2015-12-14 14:29 ` Dan
2015-12-14 15:00 ` Lukas Vrabec [this message]
2015-12-14 15:17 ` Dominick Grift
2015-12-15 3:20 ` Dan
2015-12-19 10:24 ` Dominick Grift
2015-12-14 14:57 ` Christopher J. PeBenito
2015-12-15 2:56 ` Dan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=566ED98C.6010508@redhat.com \
--to=lvrabec@redhat.com \
--cc=refpolicy@oss.tresys.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.