Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1317927 - selinux prevents systemd's ProtectSystem=full from working
Summary: selinux prevents systemd's ProtectSystem=full from working
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 24
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
Assignee: Lukas Vrabec
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedBlocker
: 1306346 1311532 1316866 1318815 1334116 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-03-15 14:28 UTC by Matthias Clasen
Modified: 2016-08-12 19:29 UTC (History)
34 users (show)

Fixed In Version: selinux-policy-3.13.1-191.10.fc24
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-08-12 19:29:27 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
more complete log (6.85 KB, text/x-vhdl)
2016-03-15 15:13 UTC, Matthias Clasen
no flags Details

Description Matthias Clasen 2016-03-15 14:28:10 UTC
I'm seeing this in my journal:


Mar 15 10:19:53 localhost audit[4221]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=4221 comm="SoftwareVsyncTh" exe="/usr/lib64/firefox/firefox" sig=11
Mar 15 10:19:53 localhost systemd-coredump[11572]: Failed to send coredump datagram: Message too long
Mar 15 10:19:53 localhost systemd[1]: Started Process Core Dump (PID 11572/UID 0).
Mar 15 10:19:53 localhost audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-coredump@4-11572-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Mar 15 10:19:53 localhost audit: NETFILTER_CFG table=filter family=2 entries=0
Mar 15 10:19:53 localhost audit: NETFILTER_CFG table=security family=2 entries=0
Mar 15 10:19:53 localhost audit: NETFILTER_CFG table=raw family=2 entries=0
Mar 15 10:19:53 localhost audit: NETFILTER_CFG table=mangle family=2 entries=0
Mar 15 10:19:53 localhost audit: NETFILTER_CFG table=nat family=2 entries=0
Mar 15 10:19:53 localhost audit: NETFILTER_CFG table=filter family=10 entries=0
Mar 15 10:19:53 localhost audit: NETFILTER_CFG table=security family=10 entries=0
Mar 15 10:19:53 localhost audit: NETFILTER_CFG table=raw family=10 entries=0
Mar 15 10:19:53 localhost audit: NETFILTER_CFG table=mangle family=10 entries=0
Mar 15 10:19:53 localhost audit: NETFILTER_CFG table=nat family=10 entries=0
Mar 15 10:19:53 localhost audit[11573]: AVC avc:  denied  { mounton } for  pid=11573 comm="(coredump)" path="/etc" dev="dm-1" ino=783362 scontext=system_u:system_r:init_t:s0 tc
Mar 15 10:19:53 localhost systemd-coredump[11573]: Coredump file descriptor missing.
Mar 15 10:19:53 localhost audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-coredump@4-11572-0 comm="systemd"

Comment 1 Ray Strode [halfline] 2016-03-15 14:32:31 UTC
maybe related to this code:

_public_ int sd_journal_sendv(const struct iovec *iov, int n) {•
...
        k = sendmsg(fd, &mh, MSG_NOSIGNAL);•
...
        if (errno != EMSGSIZE && errno != ENOBUFS)•
                return -errno;•
...
        /* Message doesn't fit... Let's dump the data in a memfd or•
         * temporary file and just pass a file descriptor of it to the•
         * other side.•
         *•
...
       buffer_fd = memfd_new(NULL);•
...
        n = writev(buffer_fd, w, j);•
...
        r = send_one_fd_sa(fd, buffer_fd, mh.msg_name, mh.msg_namelen, 0);•
...
}•

Comment 2 Paul Moore 2016-03-15 14:57:04 UTC
Any chance we can see the rest of the SELinux AVC message?  There is some important info missing, specifically the target context (tcontext).

  Mar 15 10:19:53 localhost audit[11573]: AVC avc:  denied  { mounton } for    
  pid=11573 comm="(coredump)" path="/etc" dev="dm-1" ino=783362   
  scontext=system_u:system_r:init_t:s0 tc...

The "mounton" permission is only used when mounting a filesystem, and to be honest I have no idea why systemd-coredump would be mounting something on top of /etc.  I'm equally confused suspicious about what a memfd has to do with this AVC.

Is there a reproducer for this?

Comment 3 Ray Strode [halfline] 2016-03-15 15:12:09 UTC
i think comment 1 is a red herring.  it was a guess based on this message errno:

Mar 15 10:19:53 localhost systemd-coredump[11572]: Failed to send coredump datagram: Message too long

but actually that message comes from a different part of the code:

coredump/coredump.c (send_iovec)

Comment 4 Matthias Clasen 2016-03-15 15:13:21 UTC
Created attachment 1136644 [details]
more complete log

Comment 5 Paul Moore 2016-03-15 15:27:54 UTC
Thanks for the rest of the log.

From a SELinux point of view, it would seem that systemd-coredump is trying to mount something on top of /etc; which seems odd.  I don't have any time to go digging through systemd-coredump at the moment, but does it try to mount anything?

Comment 6 Lukas Vrabec 2016-03-16 15:01:29 UTC
*** Bug 1311532 has been marked as a duplicate of this bug. ***

Comment 7 Lukas Vrabec 2016-03-16 15:13:42 UTC
*** Bug 1316866 has been marked as a duplicate of this bug. ***

Comment 8 Lukas Vrabec 2016-03-16 15:14:52 UTC
*** Bug 1306346 has been marked as a duplicate of this bug. ***

Comment 9 Lukas Vrabec 2016-03-21 12:58:54 UTC
*** Bug 1318815 has been marked as a duplicate of this bug. ***

Comment 10 Vít Ondruch 2016-04-04 16:17:21 UTC
Description of problem:
This appeared as soon as I tried to stop ABRT via:

$ sudo systemctl stop abrtd.service

Version-Release number of selected component:
selinux-policy-3.13.1-179.fc25.noarch

Additional info:
reporter:       libreport-2.6.4
hashmarkername: setroubleshoot
kernel:         4.5.0-1.fc25.x86_64
type:           libreport

Comment 11 Matthias Clasen 2016-04-04 17:45:04 UTC
This bug currently makes it impossible for me to use firefox with selinux enforcing. The combination of plugin-helper crashing, coredumpctl failing to write out the coredump, and setroubleshootd juggling the avcs (all in a loop) puts a real load on my system.

Comment 12 Fedora Blocker Bugs Application 2016-04-04 17:46:02 UTC
Proposed as a Blocker for 24-final by Fedora user mclasen using the blocker tracking app because:

 This makes firefox unusably slow on my system.

Comment 13 Kamil Páral 2016-04-11 16:53:56 UTC
Discussed at today's blocker review meeting [1]. Voted as RejectedBlocker (Final) - firefox being unusable would constitute a blocker issue, however no-one present in the blocker meeting has hit this issue in F24 testing and the bug seems unclear on exactly what configuration is required to trigger it. can be re-proposed with a clearer reproducer and blocker justification

[1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2016-04-11/

Comment 16 Göran Uddeborg 2016-05-07 21:59:11 UTC
Does comment 13 mean you need more ways to reproduce the issue?  I have one system where I can repeat the AVC every time something crashes.  If I can help with any experiments, let me know!

To reproduce, I can for example do this:

23:44 freddi$ sleep 1m&
[1] 8681
23:46 freddi$ kill -ABRT 8681

I then get an AVC like this:

time->Sat May  7 23:46:33 2016
type=AVC msg=audit(1462657593.983:4417): avc:  denied  { mounton } for  pid=8683 comm="(coredump)" path="/etc" dev="sda2" ino=7914369 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=dir permissive=0

According to the journal, pid 8683 is systemd-coredump:

maj 07 23:46:33 freddi systemd[1]: Started Process Core Dump (PID 8682/UID 0).
maj 07 23:46:34 freddi systemd-coredump[8683]: Process 8681 (sleep) of user 1003 dumped core.

It happens every time on this system, started after a number of upgrades, selinux-policy among them.  But it doesn't happen on another system that is supposed to have the same code installed.

I'm quite confused by this.  But again, if you want me to run any experiments, I'll be happy to! :-)

Comment 17 Miroslav Grepl 2016-05-09 07:35:21 UTC
*** Bug 1334116 has been marked as a duplicate of this bug. ***

Comment 18 Christophe Fergeau 2016-05-21 10:44:44 UTC
(In reply to Paul Moore from comment #5)
> From a SELinux point of view, it would seem that systemd-coredump is trying
> to mount something on top of /etc; which seems odd.  I don't have any time
> to go digging through systemd-coredump at the moment, but does it try to
> mount anything?

systemd does try to do this before (re?)starting the systemd-coredump process:

#0  mount () at ../sysdeps/unix/syscall-template.S:84
#1  0x0000558ba8f0e23c in bind_remount_recursive (prefix=0x558ba8fa2df8 "/etc", ro=true) at src/basic/mount-util.c:424
#2  0x0000558ba8f30f2e in make_read_only (m=0x7ffc1279bdd0) at src/core/namespace.c:406
#3  setup_namespace (root_directory=0x0, read_write_dirs=<optimized out>, read_only_dirs=<optimized out>, inaccessible_dirs=<optimized out>, tmp_dir=0x0, var_tmp_dir=0x0, bus_endpoint_path=0x0, 
    private_dev=false, protect_home=PROTECT_HOME_NO, protect_system=PROTECT_SYSTEM_FULL, mount_flags=1048576) at src/core/namespace.c:546
#4  0x0000558ba8f84dff in exec_child.lto_priv.895 (unit=<optimized out>, command=<optimized out>, context=0x558baae1d0d8, params=0x7ffc1279c4e0, runtime=<optimized out>, argv=<optimized out>, 
    socket_fd=<optimized out>, fds=<optimized out>, n_fds=<optimized out>, files_env=<optimized out>, exit_status=<optimized out>) at src/core/execute.c:1783
#5  0x0000558ba8f94db6 in exec_spawn (unit=0x558baae1cd20, command=0x558baad9cc50, context=0x558baae1d0d8, params=0x7ffc1279c4e0, runtime=0x558baae0b340, ret=0x7ffc1279c4d0) at src/core/execute.c:2117
#6  0x0000558ba8f4dbd0 in service_spawn.lto_priv.935 (s=s@entry=0x558baae1cd20, c=<optimized out>, timeout=timeout@entry=18446744073709551615, pass_fds=pass_fds@entry=true, 
    apply_permissions=apply_permissions@entry=true, apply_chroot=apply_chroot@entry=true, apply_tty_stdin=true, is_control=false, _pid=0x7ffc1279c644) at src/core/service.c:1301
#7  0x0000558ba8f50db0 in service_enter_start.lto_priv.934 (s=s@entry=0x558baae1cd20) at src/core/service.c:1739
#8  0x0000558ba8f51198 in service_enter_start_pre (s=0x558baae1cd20) at src/core/service.c:1816
#9  service_start.lto_priv.383 (u=0x558baae1cd20) at src/core/service.c:2027
#10 0x0000558ba8eda8f7 in unit_start (u=<optimized out>) at src/core/unit.c:1529
#11 job_perform_on_unit.lto_priv.982 (j=0x7ffc1279c6c0) at src/core/job.c:531
#12 0x0000558ba8f7d728 in job_run_and_invalidate (j=<optimized out>) at src/core/job.c:595
#13 manager_dispatch_run_queue.lto_priv.987 (source=<optimized out>, userdata=0x558baad42840) at src/core/manager.c:1444
#14 0x0000558ba8ee333f in source_dispatch.lto_priv.974 (s=0x558baad43280) at src/libsystemd/sd-event/sd-event.c:2305
#15 0x0000558ba8f7e651 in sd_event_dispatch (e=0x558baad42ff0) at src/libsystemd/sd-event/sd-event.c:2625
#16 sd_event_run (timeout=<optimized out>, e=0x558baad42ff0) at src/libsystemd/sd-event/sd-event.c:2684
#17 manager_loop (m=0x558baad42840) at src/core/manager.c:2051
#18 0x0000558ba8ebb00b in main (argc=<optimized out>, argv=<optimized out>) at src/core/main.c:1833

(backtrace generated with gdb --pid 1; set follow-fork-mode child; break mount, and then running a program which abort() )
It's doing some more mounting before/after that (/boot, ...). If it's setting up some kind of container to run systemd-coredump in it, the mounting might be legit.

Comment 19 Matthias Clasen 2016-05-31 19:14:27 UTC
This is happening because systemd-coredump@.service has the line
ProtectSystem=full

According to systemd.exec(5):

       ProtectSystem=
           Takes a boolean argument or "full". If true, mounts the /usr and /boot
           directories read-only for processes invoked by this unit. If set to
           "full", the /etc directory is mounted read-only, too. This setting
           ensures that any modification of the vendor-supplied operating system
           (and optionally its configuration) is prohibited for the service. It is
           recommended to enable this setting for all long-running services, unless
           they are involved with system updates or need to modify the operating
           system in other ways. Note however that processes retaining the
           CAP_SYS_ADMIN capability can undo the effect of this setting. This
           setting is hence particularly useful for daemons which have this
           capability removed, for example with CapabilityBoundingSet=. Defaults to
           off.


So, I would say the selinux policy is in the wrong to prevent this, and needs fixing.

Comment 20 Paul Moore 2016-05-31 19:32:49 UTC
Huh, that's something.  I'm not sure if I like the ProtectSystem=full or not.

Another option, assuming systemd can handle the failure, would be to add a dontaudit rule instead of granting access.

Comment 21 Matthias Clasen 2016-05-31 20:40:30 UTC
(In reply to Paul Moore from comment #20)
> Huh, that's something.  I'm not sure if I like the ProtectSystem=full or not.
> 
> Another option, assuming systemd can handle the failure, would be to add a
> dontaudit rule instead of granting access.

I think all the duplicates on this bug are a clear indication that systemd can't.

But granting systemd this access is a good thing: You give a small amount of code (systemd) the privilege to set things up so that much larger amounts of code (all the system daemons with ProtectSystem=full in their service file) can run will less access to the system.

Comment 22 Paul Moore 2016-05-31 20:51:38 UTC
(In reply to Matthias Clasen from comment #21)
> (In reply to Paul Moore from comment #20)
> > Huh, that's something.  I'm not sure if I like the ProtectSystem=full or not.
> > 
> > Another option, assuming systemd can handle the failure, would be to add a
> > dontaudit rule instead of granting access.
> 
> I think all the duplicates on this bug are a clear indication that systemd
> can't.

I see lots of people complaining about AVCs in their systemd journal, but I only see one comment about the coredump failing (comment #11).  Can you confirm that the systemd coredump service fails to produce a coredump?  The AVC error messages don't necessarily mean that the systemd coredump service failed to work.

> But granting systemd this access is a good thing: You give a small amount of
> code (systemd) the privilege to set things up so that much larger amounts of
> code (all the system daemons with ProtectSystem=full in their service file)
> can run will less access to the system.

It depends on your perspective and use case; from your perspective the solution is obvious, for others I'm not certain at this point.  I haven't thought about this very much, but granting mounton permissions for /etc isn't something I would undertake lightly.

Comment 23 Christophe Fergeau 2016-06-01 08:43:28 UTC
(In reply to Paul Moore from comment #22)
> (In reply to Matthias Clasen from comment #21)
> > (In reply to Paul Moore from comment #20)
> > > Huh, that's something.  I'm not sure if I like the ProtectSystem=full or not.
> > > 
> > > Another option, assuming systemd can handle the failure, would be to add a
> > > dontaudit rule instead of granting access.
> > 
> > I think all the duplicates on this bug are a clear indication that systemd
> > can't.
> 
> I see lots of people complaining about AVCs in their systemd journal, but I
> only see one comment about the coredump failing (comment #11).  Can you
> confirm that the systemd coredump service fails to produce a coredump?  The
> AVC error messages don't necessarily mean that the systemd coredump service
> failed to work.

I was under the impression that this AVC was actually preventing the core generation even though coredumpctl shows it (ie coredumpctl gdb xxx fails saying there is no core file), but after running more tests, I cannot get it to produce core files even with setenforce 0, so dunno what's going on :((

Comment 24 Paul Moore 2016-06-01 19:38:34 UTC
(In reply to Christophe Fergeau from comment #23)
> I was under the impression that this AVC was actually preventing the core
> generation even though coredumpctl shows it (ie coredumpctl gdb xxx fails
> saying there is no core file), but after running more tests, I cannot get it
> to produce core files even with setenforce 0, so dunno what's going on :((

Can anyone else confirm this behavior?

Comment 25 Göran Uddeborg 2016-06-01 19:47:11 UTC
I hadn't tried, but yes, it's the same for me.

mimmi$ getenforce
Permissive
mimmi$ sleep 30
^\Quit (core dumped)
mimmi$ coredumpctl
TIME                            PID   UID   GID SIG PRESENT EXE
...
ons 2016-06-01 21:44:38 CEST  13065  1003  1003   3   /usr/bin/sleep
mimmi$ coredumpctl gdb 13065
           PID: 13065 (sleep)
           UID: 1003 (göran)
           GID: 1003 (göran)
        Signal: 3 (QUIT)
     Timestamp: ons 2016-06-01 21:44:38 CEST (13s ago)
  Command Line: sleep 30
    Executable: /usr/bin/sleep
 Control Group: /user.slice/user-1003.slice/session-1806.scope
          Unit: session-1806.scope
         Slice: user-1003.slice
       Session: 1806
     Owner UID: 1003 (göran)
       Boot ID: 6a333211d9d34218a6b92e299146ee7a
    Machine ID: 606ba17eef1ffa5a76fdb50047756efd
      Hostname: mimmi
       Message: Process 13065 (sleep) of user 1003 dumped core.

Cannot retrieve coredump from journal nor disk.
Failed to retrieve core: No such file or directory

Comment 26 Paul Moore 2016-06-01 19:50:02 UTC
Regardless of the SELinux policy, perhaps there is an issue with systemd-coredump.

Comment 27 Göran Uddeborg 2016-06-01 19:59:49 UTC
Indeed.  I filed a separate bug 1341829 about it.

Comment 28 Mike Goodwin 2016-06-05 08:44:55 UTC
Description of problem:
Started seeing this after upgrading F23 to F24. Even after a /.autorelabel 

Version-Release number of selected component:
selinux-policy-3.13.1-190.fc24.noarch

Additional info:
reporter:       libreport-2.7.1
hashmarkername: setroubleshoot
kernel:         4.5.5-300.fc24.x86_64
reproducible:   Not sure how to reproduce the problem
type:           libreport

Comment 29 Matthias Clasen 2016-06-22 15:22:56 UTC
Did we get any closer to a fix for the selinux policy that stops it from breaking a designed systemd feature that is meant to protect the system ?

Comment 30 Christophe Fergeau 2016-06-22 15:35:30 UTC
After more testing, the selinux alert does not seem to prevent the generation of the core file. 'ulimit -c unlimited' is required though as explained in https://bugzilla.redhat.com/show_bug.cgi?id=1341829#c1

« Michael Catanzaro 2016-06-04 09:44:41 EDT

You have to set ulimit now (and disable SELinux, bug #1317927) for systemd-coredump to work in F24. This really sucks; neither was required in F23.

I was hoping that having coredumpctl enabled by default could be a F25 feature thanks to recent integration work by the ABRT team, but looks like that requires either setting ulimit systemwide (probably preferable) or reverting the change to respect ulimit. »

Comment 31 Paul Moore 2016-06-22 19:53:27 UTC
Policy guys (mgrepl,lvrabec), I suggest bringing this up to the upstream SELinux list for discussion.

Comment 32 Jakub Filak 2016-06-23 07:41:00 UTC
(In reply to Christophe Fergeau from comment #30)
> After more testing, the selinux alert does not seem to prevent the
> generation of the core file. 'ulimit -c unlimited' is required though as
> explained in https://bugzilla.redhat.com/show_bug.cgi?id=1341829#c1

RLIMIT_CORE (ulimit -c) should be 'unlimited' by default (bug #1341829 comment #2).

Comment 33 George Joseph 2016-07-04 16:37:04 UTC
Just chiming in with a possible (temporary) solution...

In my case, it was a crash of Asterisk that was causing the failure, specifically "failed to send coredump datagram: Message too long", even with selinux disabled and ulimit -c 0.  Turns out that since coredump.c/send_iovec doesn't do any buffering, when it tries to send a large COREDUMP_PROC_MAPS that exceeds /proc/sys/net/core/wmem_default, sendto fails with EMSGSIZE.

Increasing /proc/sys/net/core/wmem_default and wmem_max fixed the issue for me.

The real solution should be for coredump.c/send_iovec to buffer messages that exceed wmem_default and/or wmem_max.

Comment 34 Jan Kurik 2016-07-26 04:44:32 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle.
Changing version to '25'.

Comment 35 Sergey 2016-07-27 23:42:00 UTC
Description of problem:
Install tor using dnf install tor command
sudo systemctl enable tor
sudo systemctl start tor
sudo systemctl status tor
июл 28 02:00:13 localhost.localdomain Tor[17064]: Bootstrapped 45%: Asking for relay d
июл 28 02:00:13 localhost.localdomain Tor[17064]: I learned some more directory inform
июл 28 02:00:14 localhost.localdomain Tor[17064]: Bootstrapped 50%: Loading relay desc
июл 28 02:00:15 localhost.localdomain Tor[17064]: Bootstrapped 58%: Loading relay desc
июл 28 02:00:15 localhost.localdomain Tor[17064]: Bootstrapped 66%: Loading relay desc
июл 28 02:00:15 localhost.localdomain Tor[17064]: Bootstrapped 72%: Loading relay desc
июл 28 02:00:16 localhost.localdomain Tor[17064]: Bootstrapped 80%: Connecting to the 
июл 28 02:00:16 localhost.localdomain Tor[17064]: Bootstrapped 90%: Establishing a Tor
июл 28 02:00:16 localhost.localdomain Tor[17064]: Tor has successfully opened a circui
июл 28 02:00:16 localhost.localdomain Tor[17064]: Bootstrapped 100%: Done
then setup firefox for using tor sock4a port 9050 actually tor working normally as intended after these steps but I've got these messages:
SELinux is preventing (tor) from mounton access on the directory /etc.

Модуль: catchall_labels
you want to allow (tor) to have mounton access on the etc directoryЕсли you want to allow (tor) to have mounton access on the etc directory
Необходимо изменить метку на /etc
# semanage fcontext -a -t FILE_TYPE '/etc'      - PLEASE GIVE ME ADVICE WHAT I NEED TO PUT INTO FILE_TYPE VARIABLE FOR TOR!!! I HAVE NO CLUE WHAT TO DO AND WRITE IN THESE COMMAND, THE SECOND TIP BY TWO COMMANDS WHICH CREATES CUSTOM SELINUX POLICY IS WORKED OUT FOR ME, THANK YOU!!!
where FILE_TYPE is one of the following: admin_home_t, anon_inodefs_t, audit_spool_t, auditd_log_t, autofs_t, automount_tmp_t, bacula_store_t, binfmt_misc_fs_t, boot_t, capifs_t, cephfs_t, cgroup_t, cifs_t, container_image_t, debugfs_t, default_t, device_t, devpts_t, dnssec_t, dosfs_t, ecryptfs_t, efivarfs_t, fusefs_t, home_root_t, hugetlbfs_t, ifconfig_var_run_t, init_var_run_t, initrc_tmp_t, iso9660_t, kdbusfs_t, mail_spool_t, mnt_t, mqueue_spool_t, named_conf_t, news_spool_t, nfs_t, nfsd_fs_t, openshift_tmp_t, openshift_var_lib_t, oracleasmfs_t, proc_t, proc_xen_t, pstore_t, public_content_rw_t, public_content_t, ramfs_t, random_seed_t, removable_t, root_t, rpc_pipefs_t, security_t, spufs_t, src_t, svirt_sandbox_file_t, sysctl_fs_t, sysctl_t, sysfs_t, sysv_t, tmp_t, tmpfs_t, usbfs_t, user_home_dir_t, user_home_t, user_tmp_t, usr_t, var_lib_nfs_t, var_lib_t, var_lock_t, var_log_t, var_run_t, var_t, virt_image_t, virt_var_lib_t, vmblock_t, vxfs_t, xend_var_lib_t, xend_var_run_t, xenfs_t, xenstored_var_lib_t.
Then execute:
restorecon -v '/etc'

and

SELinux is preventing (tor) from mounton access on the directory /etc.

Модуль: catchall
you want to allow (tor) to have mounton access on the etc directoryЕсли вы считаете, что (tor) следует разрешить доступ mounton к etc directory по умолчанию.
Рекомендуется создать отчет об ошибке.
Чтобы разрешить доступ, можно создать локальный модуль политики.
Allow this access for now by executing:
# ausearch -c '(tor)' --raw | audit2allow -M my-tor
# semodule -X 300 -i my-tor.pp

then these when error reporting

SELinux is preventing (tor) from 'mounton' accesses on the directory /etc.

*****  Plugin catchall_labels (83.8 confidence) suggests   *******************

If you want to allow (tor) to have mounton access on the etc directory
Then необходимо изменить метку на /etc
Do
# semanage fcontext -a -t FILE_TYPE '/etc'
where FILE_TYPE is one of the following: admin_home_t, anon_inodefs_t, audit_spool_t, auditd_log_t, autofs_t, automount_tmp_t, bacula_store_t, binfmt_misc_fs_t, boot_t, capifs_t, cephfs_t, cgroup_t, cifs_t, container_image_t, debugfs_t, default_t, device_t, devpts_t, dnssec_t, dosfs_t, ecryptfs_t, efivarfs_t, fusefs_t, home_root_t, hugetlbfs_t, ifconfig_var_run_t, init_var_run_t, initrc_tmp_t, iso9660_t, kdbusfs_t, mail_spool_t, mnt_t, mqueue_spool_t, named_conf_t, news_spool_t, nfs_t, nfsd_fs_t, openshift_tmp_t, openshift_var_lib_t, oracleasmfs_t, proc_t, proc_xen_t, pstore_t, public_content_rw_t, public_content_t, ramfs_t, random_seed_t, removable_t, root_t, rpc_pipefs_t, security_t, spufs_t, src_t, svirt_sandbox_file_t, sysctl_fs_t, sysctl_t, sysfs_t, sysv_t, tmp_t, tmpfs_t, usbfs_t, user_home_dir_t, user_home_t, user_tmp_t, usr_t, var_lib_nfs_t, var_lib_t, var_lock_t, var_log_t, var_run_t, var_t, virt_image_t, virt_var_lib_t, vmblock_t, vxfs_t, xend_var_lib_t, xend_var_run_t, xenfs_t, xenstored_var_lib_t.
Then execute:
restorecon -v '/etc'


*****  Plugin catchall (17.1 confidence) suggests   **************************

If вы считаете, что (tor) следует разрешить доступ mounton к etc directory по умолчанию.
Then рекомендуется создать отчет об ошибке.
Чтобы разрешить доступ, можно создать локальный модуль политики.
Do
allow this access for now by executing:
# ausearch -c '(tor)' --raw | audit2allow -M my-tor
# semodule -X 300 -i my-tor.pp

Additional Information:
Source Context                system_u:system_r:init_t:s0
Target Context                system_u:object_r:etc_t:s0
Target Objects                /etc [ dir ]
Source                        (tor)
Source Path                   (tor)
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           
Target RPM Packages           filesystem-3.2-37.fc24.x86_64
Policy RPM                    selinux-policy-3.13.1-191.5.fc24.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed) 4.5.5-300.fc24.x86_64 #1 SMP Thu
                              May 19 13:05:32 UTC 2016 x86_64 x86_64
Alert Count                   3
First Seen                    2016-07-28 02:00:05 MSK
Last Seen                     2016-07-28 02:02:55 MSK
Local ID                      232edcff-3325-49a3-8a55-ea5a8d170f22

Raw Audit Messages
type=AVC msg=audit(1469660575.66:765): avc:  denied  { mounton } for  pid=17137 comm="(tor)" path="/etc" dev="dm-0" ino=917505 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=dir permissive=0


Hash: (tor),init_t,etc_t,dir,mounton

Version-Release number of selected component:
selinux-policy-3.13.1-191.5.fc24.noarch

Additional info:
reporter:       libreport-2.7.2
hashmarkername: setroubleshoot
kernel:         4.5.5-300.fc24.x86_64
type:           libreport

Comment 36 Matěj Koudelka 2016-08-04 09:02:28 UTC
Description of problem:
1/ First I have done upgrade from Fedora23 to Fedora24
2/ Than java application (PHPStorm) has started fall down and no coredump was available
When I run command: coredumpctl dump java -o java_dump.log
Got this error:
"Cannot retrieve coredump from journal nor disk."
"Coredump retrieval failed: No such file or directory"
3/ touch /.autorelabel && reboot
4/ Test coredump again and receive this SELinux alert.

Version-Release number of selected component:
selinux-policy-3.13.1-191.5.fc24.noarch

Additional info:
reporter:       libreport-2.7.2
hashmarkername: setroubleshoot
kernel:         4.6.4-301.fc24.x86_64
type:           libreport

Comment 37 Matěj Koudelka 2016-08-04 10:16:48 UTC
I have disabled ProtectSystem in service systemd-coredump, and try to kill -ABRT process sleep. SElinux alert is away, but there is same result.
Cannot retrieve coredump from journal nor disk.
Coredump retrieval failed: No such file or directory
So it looks like that my primary problem is with coredump? Or do I something wrong? I have no experience with coredumping.

Comment 38 Christophe Fergeau 2016-08-04 11:05:30 UTC
Matej, have you read comment #30 and the other bug report it mentions?

« After more testing, the selinux alert does not seem to prevent the generation of the core file. 'ulimit -c unlimited' is required though as explained in https://bugzilla.redhat.com/show_bug.cgi?id=1341829#c1

« Michael Catanzaro 2016-06-04 09:44:41 EDT

You have to set ulimit now (and disable SELinux, bug #1317927) for systemd-coredump to work in F24. This really sucks; neither was required in F23.

I was hoping that having coredumpctl enabled by default could be a F25 feature thanks to recent integration work by the ABRT team, but looks like that requires either setting ulimit systemwide (probably preferable) or reverting the change to respect ulimit. »

Comment 39 Matěj Koudelka 2016-08-04 11:23:51 UTC
Christophe, thanks.
I have omitted this comment.
Setting ulimit helps me, even if I have SElinux in Enforced state.

Comment 40 Zbigniew Jędrzejewski-Szmek 2016-08-09 16:25:21 UTC
Selinux policy was updated to allow mounton in https://github.com/fedora-selinux/selinux-policy/commit/257f2a8a44a039eb298b7c04508fa2db93983807 (rawhide), https://github.com/fedora-selinux/selinux-policy/commit/78216c32fd090c691eadf973c5dc7c87d17b3c9e (F24). This seems to work in rawhide (no AVC, ProtectSystem works), BUT DOES NOT WORK IN F24 (AVC, ProtectSystem=full does not work).

Reproducer:
$ systemctl cat test-pf
# /run/systemd/system/test-pf.service
[Service]
ProtectSystem=full
Type=oneshot
ExecStart=/bin/touch /etc/test-protect-system-full
ExecStart=/bin/touch /boot/test-protect-system-full
ExecStart=/bin/touch /usr/test-protect-system-full

$ systemctl start test-pf &>/dev/null
$  ls /*/test-protect-system-full
/etc/test-protect-system-full

Logs:
Aug 09 12:21:42 systemd[1]: Starting test-pf.service...
Aug 09 12:21:42 audit[15472]: AVC avc:  denied  { mounton } for  pid=15472 comm="(touch)" path="/etc" dev="dm-0" ino=1179649 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=dir permissive=0
Aug 09 12:21:42 audit[15480]: AVC avc:  denied  { mounton } for  pid=15480 comm="(touch)" path="/etc" dev="dm-0" ino=1179649 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=dir permissive=0
Aug 09 12:21:42 touch[15480]: /bin/touch: cannot touch '/boot/test-protect-system-full': Read-only file system
Aug 09 12:21:42 systemd[1]: test-pf.service: Main process exited, code=exited, status=1/FAILURE
Aug 09 12:21:42 systemd[1]: Failed to start test-pf.service.

$ rpm -q selinux-policy-targeted
selinux-policy-targeted-3.13.1-191.8.fc24.noarch

Comment 41 Zbigniew Jędrzejewski-Szmek 2016-08-09 16:27:57 UTC
Let's make this bug about the AVC denial and ProtectSystem=full and handle other coredump issues in #1309172.

Comment 42 Fedora Update System 2016-08-11 11:57:50 UTC
selinux-policy-3.13.1-191.10.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-2c8a3e08c6

Comment 43 Fedora Update System 2016-08-12 19:28:39 UTC
selinux-policy-3.13.1-191.10.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.


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