Bug 705768 - Enable third-party ABRT event scripts in SELinux policy
Summary: Enable third-party ABRT event scripts in SELinux policy
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: abrt
Version: 6.2
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Jiri Moskovcak
QA Contact: qe-baseos-tools-bugs
URL:
Whiteboard:
: 726117 (view as bug list)
Depends On: 705767
Blocks: 678564
TreeView+ depends on / blocked
 
Reported: 2011-05-18 12:05 UTC by Michal Nowak
Modified: 2015-02-01 22:53 UTC (History)
10 users (show)

Fixed In Version: abrt-2.0.4-3.el6
Doc Type: Bug Fix
Doc Text:
Clone Of: 705767
Environment:
Last Closed: 2011-12-06 12:13:51 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:1598 0 normal SHIPPED_LIVE abrt and libreport bug fix and enhancement update 2011-12-06 00:51:16 UTC

Comment 6 Daniel Walsh 2011-07-21 13:21:26 UTC
/etc/abrt/events.d should have an abrt_unconfined_exec_t label associated with it, Any abrt scripts added by a user would automatically get this type and abrt would transition to abrt_unconfined_t which will be unconfined_domain(abrt_unconfined_t).

Any thing shipped by abrt in this directory should have a separate label, and removing the unconfined.pp package will cause these executables to run within the abrt domain.

Comment 7 Miroslav Grepl 2011-07-25 11:43:27 UTC
Yes, but the problem is the following (if I understand correctly).

ABRT places *.conf files there (/etc/abrt/events.d) and includes them into abrt_event.conf, parse them and after that abrt executes appropriate command.

So we would need to add a script/binary which would execute these commands. Then we could add a label for this script/binary.

abrt_t -> abrt_events_exec-t -> abrt_events_t


and make abrt_events_t as unconfined domain probably.

Comment 8 Daniel Walsh 2011-07-25 15:42:20 UTC
Are you saying they are putting shell code within the conf?

Comment 9 Jiri Moskovcak 2011-07-25 16:26:11 UTC
It's technically not a config file, but yes, we have a file which contains actions to run when processing the crash and these actions can be shell script (directly written in that file). You can take a look at /etc/libreport/events.d/abrt_event.conf

Comment 10 Daniel Walsh 2011-07-25 18:42:04 UTC
Ok then I would like to have an intermediate program/shell that gets executed so we can do a transition on the file.  I also would like a big boolean to be turned off by default for this action.

Comment 11 Denys Vlasenko 2011-07-26 16:09:36 UTC
(In reply to comment #8)
> Are you saying they are putting shell code within the conf?

The conf file looks like this:


EVENT=foo [other conditions in the form of VAR=VAL]
    shell code
    shell code
    shell code


Shell code gets executed by abrtd by spawning:

sh -c 'shell code\nshell code\nshell code'


(In reply to comment #10)
> Ok then I would like to have an intermediate program/shell that gets executed
> so we can do a transition on the file.

You need abrtd to spawn some sort of intermediate helper binary which will then exec sh -c '...'?

Comment 12 Miroslav Grepl 2011-07-28 12:08:50 UTC
Yes, we need ABRT executing intermediate helper binary which will execute shell code.

Then we will have the following situation

abrt @intermediate helper binary @sh -c 'shell code\nshell code\nshell code'

We will label @intermediate_helper_binary as abrt_events_exec_t and we will get the following transition


abrt_t -> abrt_events_exec_t -> abrt_events_t

Comment 13 Miroslav Grepl 2011-07-28 12:40:52 UTC
*** Bug 726117 has been marked as a duplicate of this bug. ***

Comment 15 Michal Nowak 2011-08-17 11:19:12 UTC
Guys, I am confused.

Bug 726117 is dupe of this one, which is currently ON_QA. Having latest abrt/libreport/selinux-policy I still can see the issue reported in bug 726117.



And to the point of this bug: Created `/etc/libreport/events.d/wall.conf' containing just

EVENT=post-create
        echo abrt: Crash in $(cat package) detected: $(cat reason) | wall

changed context to match the rest of the config files (i.e. system_u:object_r:etc_t:s0), crashed `sleep' and got the same AVC:

SELinux is preventing /usr/bin/wall from read access on the file /var/run/utmp.

*****  Plugin catchall (100. confidence) suggests  ***************************

If you believe that wall should be allowed read access on the utmp file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep wall /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:abrt_t:s0-s0:c0.c1023
Target Context                system_u:object_r:initrc_var_run_t:s0
Target Objects                /var/run/utmp [ file ]
Source                        wall
Source Path                   /usr/bin/wall
Port                          <Unknown>
Host                          dhcp-25-35.brq.redhat.com
Source RPM Packages           sysvinit-tools-2.87-4.dsf.el6
Target RPM Packages           initscripts-9.03.23-1.el6
Policy RPM                    selinux-policy-3.7.19-107.el6
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     dhcp-25-35.brq.redhat.com
Platform                      Linux dhcp-25-35.brq.redhat.com
                              2.6.32-184.el6.x86_64 #1 SMP Tue Aug 9 12:20:06
                              EDT 2011 x86_64 x86_64
Alert Count                   3
First Seen                    Wed 17 Aug 2011 12:54:11 PM CEST
Last Seen                     Wed 17 Aug 2011 01:11:12 PM CEST
Local ID                      0937414b-acb2-44dc-9753-30100180dcef

Raw Audit Messages
type=AVC msg=audit(1313579472.993:36839): avc:  denied  { read } for  pid=9961 comm="wall" name="utmp" dev=dm-1 ino=20 scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tcontext=system_u:object_r:initrc_var_run_t:s0 tclass=file


type=SYSCALL msg=audit(1313579472.993:36839): arch=x86_64 syscall=open success=no exit=EACCES a0=358df64145 a1=80000 a2=358df64145 a3=180 items=0 ppid=1 pid=9961 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=5 sgid=5 fsgid=5 tty=(none) ses=4294967295 comm=wall exe=/usr/bin/wall subj=system_u:system_r:abrt_t:s0-s0:c0.c1023 key=(null)

Hash: wall,abrt_t,initrc_var_run_t,file,read

audit2allow

#============= abrt_t ==============
allow abrt_t initrc_var_run_t:file read;

audit2allow -R

#============= abrt_t ==============
allow abrt_t initrc_var_run_t:file read;




I thought the immediate helper will fix the third-party hooks.

Comment 16 Jiri Moskovcak 2011-08-17 11:47:21 UTC
I guess the policy for the helper is still not finished ..

Comment 17 Daniel Walsh 2011-08-17 12:44:21 UTC
Are you executing a helper yet, we can not do anything if abrt is going to execute any random app on demand.  We need to allow a helper app that would read the config files and then execute it.  Then we can give the helper app the unconfined privs without having to give all of abort the privs.

Comment 18 Jiri Moskovcak 2011-08-17 13:32:01 UTC
(In reply to comment #17)
> Are you executing a helper yet, we can not do anything if abrt is going to
> execute any random app on demand.  

- yes, it's /usr/libexec/abrt-handle-event

> We need to allow a helper app that would
> read the config files and then execute it.  Then we can give the helper app the
> unconfined privs without having to give all of abort the privs.

- I thought mgrepl did this already, that's what I meant by c#16

Comment 19 Miroslav Grepl 2011-08-22 08:38:01 UTC
We have in policy

abrt.fc

/usr/libexec/abrt-handle-event  --  gen_context(system_u:object_r:abrt_handle_event_exec_t,s0)


abrt.te

allow abrt_handle_event_t self:fifo_file rw_fifo_file_perms;

tunable_policy(`abrt_handle_event',`
    domtrans_pattern(abrt_t, abrt_handle_event_exec_t, abrt_handle_event_t)
',`
    can_exec(abrt_t, abrt_handle_event_exec_t)
')

optional_policy(`
    unconfined_domain(abrt_handle_event_t)
')



So just try to turn on the abrt_handle_event boolean.

setsebool -P abrt_handle_event 1

Comment 20 Michal Nowak 2011-08-22 09:22:19 UTC
(In reply to comment #19)
> So just try to turn on the abrt_handle_event boolean.
> 
> setsebool -P abrt_handle_event 1


It works! Thanks.

Broadcast message from root.redhat.com (Mon Aug 22 11:19:25 2011):

abrt: Crash in coreutils-8.4-14.el6 detected: Process /bin/sleep was killed by 
signal 11 (SIGSEGV)


Jiří, make sure it's documented in 6.2 docs, please.

Comment 21 Miroslav Grepl 2011-08-24 14:52:24 UTC
Michal,
how about this man page:

--

abrt_selinux(8)        ABRT SELinux Policy documentation       abrt_selinux(8)

NAME
       abrt_selinux - Security-Enhanced Linux Policy for the ABRT daemon

DESCRIPTION
       Security-Enhanced Linux (SELinux) secures the squid server via flexible mandatory access control.

SHARING FILES
       If   you  want  to share files with multiple domains (Apache, FTP, rsync, Samba, ABRT), you can set a file context
       of public_content_t and public_content_rw_t. These context allow any of the above domains to read the content.  If
       you  want   a   particular   domain  to  write  to  the  public_content_rw_t  domain, you must set the appropriate
       boolean. DOMAIN_anon_write.  So for ABRT you would execute:

       setsebool -P abrt_anon_write 1

BOOLEANS
       If  you  want  to allow ABRT to run ABRT event scripts properly, you need to set the abrt_handle_event boolean on.
       Then an event script will run in the own SELinux domain.

       setsebool -P abrt_handle_event 1

       Note  that you can also use the system-config-selinux utility that allows you to customize SELinux policy settings
       in the graphical user interface.

AUTHOR
       This manual page was written by Miroslav Grepl <mgrepl>.

Comment 22 Michal Nowak 2011-08-25 09:17:17 UTC
(In reply to comment #21)
> DESCRIPTION
>        Security-Enhanced Linux (SELinux) secures the squid server via flexible
> mandatory access control.
> 
`------------------------------------------------------^^^^^^^^^^^^--------------

This does not seem to be correct.

The rest was OK. Thank you.

I'd be also nice if administrator could find information that such a man page exists somewhere (errata docs, deployment guide).

Comment 23 Miroslav Grepl 2011-08-25 09:27:05 UTC
Yeap. Thanks.

I opened the following bug

https://bugzilla.redhat.com/show_bug.cgi?id=733039

so it will be part of errata docs to selinux-policy at least.

Comment 25 errata-xmlrpc 2011-12-06 12:13:51 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2011-1598.html


Note You need to log in before you can comment on or make changes to this bug.