Bug 1317927
Summary: | selinux prevents systemd's ProtectSystem=full from working | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Matthias Clasen <mclasen> | ||||
Component: | selinux-policy | Assignee: | Lukas Vrabec <lvrabec> | ||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | high | ||||||
Version: | 24 | CC: | akees, amessina, beaaegicfqmq6rykaqaakty3lqcg6btv, bugzilla, cfergeau, cogre666, dominick.grift, dwalsh, fedora, g.devel, goeran, guo888xiao, jfilak, kparal, lvrabec, mark.harfouche, matej, mcatanzaro+wrong-account-do-not-cc, mclasen, mgrepl, mike, mvollmer, nicolas.mailhot, ol+redhat, plautrba, pmoore, robatino, rstrode, tpopela, vondruch, yaneti, zach, zbyszek, zor1984qq | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | RejectedBlocker | ||||||
Fixed In Version: | selinux-policy-3.13.1-191.10.fc24 | Doc Type: | Bug Fix | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2016-08-12 19:29:27 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Matthias Clasen
2016-03-15 14:28:10 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);• ... }• 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? 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) Created attachment 1136644 [details]
more complete log
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? *** Bug 1311532 has been marked as a duplicate of this bug. *** *** Bug 1316866 has been marked as a duplicate of this bug. *** *** Bug 1306346 has been marked as a duplicate of this bug. *** *** Bug 1318815 has been marked as a duplicate of this bug. *** 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 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. 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. 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/ 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! :-) *** Bug 1334116 has been marked as a duplicate of this bug. *** (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. 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. 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. (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. (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. (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 :(( (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? 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 Regardless of the SELinux policy, perhaps there is an issue with systemd-coredump. Indeed. I filed a separate bug 1341829 about it. 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 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 ? 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. » Policy guys (mgrepl,lvrabec), I suggest bringing this up to the upstream SELinux list for discussion. (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). 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. This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle. Changing version to '25'. 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 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 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. 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. » Christophe, thanks. I have omitted this comment. Setting ulimit helps me, even if I have SElinux in Enforced state. 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 Let's make this bug about the AVC denial and ProtectSystem=full and handle other coredump issues in #1309172. 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 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. |