Description of problem:systemctl start smb.service returns Job for smb.service failed. Version-Release number of selected component (if applicable): samba.x86_64 4.1.0-0.6.rc2.fc20 How reproducible: 100% Steps to Reproduce: 1.Install Fedora 20 from Live Desktop . 2.Install samba. 3.Systemctl enable smb.service. Systemctl start smb.service Actual results:samba doesn't start. Expected results:samba starts. Additional info:systemctl status smb.service returns: Sep 30 20:02:29 amkl.garlies.ca systemd[1]: Starting Samba SMB Daemon... Sep 30 20:02:29 amkl.garlies.ca smbd[3274]: [2013/09/30 20:02:29.587287, 0] ../source3/profile/profile.c:155(profile_setup) Sep 30 20:02:29 amkl.garlies.ca smbd[3274]: Can't attach to IPC area. Error was Permission denied Sep 30 20:02:29 amkl.garlies.ca smbd[3274]: [2013/09/30 20:02:29.587685, 0] ../source3/smbd/server.c:1263(main) Sep 30 20:02:29 amkl.garlies.ca smbd[3274]: ERROR: failed to setup profiling Sep 30 20:02:29 amkl.garlies.ca systemd[1]: smb.service: control process exited, code=exited status=255 Sep 30 20:02:29 amkl.garlies.ca systemd[1]: Failed to start Samba SMB Daemon. Sep 30 20:02:29 amkl.garlies.ca systemd[1]: Unit smb.service entered failed state.
smbd tries to attach to a shared memory segment and fails, which is really strange. Is it possible that SELinux blocks shared memory access? Alexander can you help?
What I see in the code: 0. smbd compiled with profiling support. 1. We attempt to open shared memory segment 0x07021999 2. If that fails (it didn't exist, for example), we attempt to create it. 3. If that fails, the message above is displayed and smbd exits. There could be two issues here: 1. The shared memory segment exists and is owned by somebody else already with access rights preventing root to access it. This is unlikely situation. 2. The shared memory segment does not exist and we attempt to create it. Being a root at this point, shmget() returns EACCESS (Permission denied) only in case SELinux denial has happened or a process lacks CAP_IPC_OWNER capability. Daniel, can we see /var/log/audit/audit.log?
type=SYSCALL msg=audit(1380788390.940:1043): arch=c000003e syscall=30 success=no exit=-13 a0=480000 a1=0 a2=0 a3=7f4537728230 items=0 ppid=1 pid=17006 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm="smbd" exe="/usr/sbin/smbd" subj=system_u:system_r:smbd_t:s0 key=(null) type=AVC msg=audit(1380788390.940:1043): avc: denied { read write } for pid=17006 comm="smbd" path=2F535953563037303231393939202864656C6574656429 dev="tmpfs" ino=4718592 scontext=system_u:system_r:smbd_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=file Oct 3 10:19:52 faldor setroubleshoot: SELinux is preventing /usr/sbin/smbd from 'read, write' accesses on the file /SYSV07021999 (deleted). For complete SELinux messages. run sealert -l 5f6e8631-6572-40b0-bbab-0554e2167d89
My system has the error since the upgrade from Fedora 19 to Fedora 20 (fedup). Selinux labels seem OK, I also tried to reinstall samba. Samba version is 2:4.1.1-1.fc20. Could https://bugzilla.redhat.com/show_bug.cgi?id=1031896 be a duplicate of this?
(In reply to Michael Schwendt from comment #3) > type=SYSCALL msg=audit(1380788390.940:1043): arch=c000003e syscall=30 > success=no exit=-13 a0=480000 a1=0 a2=0 a3=7f4537728230 items=0 ppid=1 > pid=17006 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 > fsgid=0 ses=4294967295 tty=(none) comm="smbd" exe="/usr/sbin/smbd" > subj=system_u:system_r:smbd_t:s0 key=(null) > type=AVC msg=audit(1380788390.940:1043): avc: denied { read write } for > pid=17006 comm="smbd" path=2F535953563037303231393939202864656C6574656429 > dev="tmpfs" ino=4718592 scontext=system_u:system_r:smbd_t:s0 > tcontext=system_u:object_r:tmpfs_t:s0 tclass=file > > Oct 3 10:19:52 faldor setroubleshoot: SELinux is preventing /usr/sbin/smbd > from 'read, write' accesses on the file /SYSV07021999 (deleted). For > complete SELinux messages. run sealert -l > 5f6e8631-6572-40b0-bbab-0554e2167d89 So, it looks like the it is indeed SELinux policy issue. We need shared memory segment to allow profiling support. Dan, could we get SELinux policy amended? (In reply to Jörg Klemenz from comment #4) > My system has the error since the upgrade from Fedora 19 to Fedora 20 > (fedup). > > Selinux labels seem OK, I also tried to reinstall samba. Samba version is > 2:4.1.1-1.fc20. > > Could https://bugzilla.redhat.com/show_bug.cgi?id=1031896 be a duplicate of > this? Perhaps. Note that it has other SELinux alerts too, those couldn't be explained by profiling support in action.
Could this be a kernel bug similar to the one on the kernel keyring. Since this shared memory segment is not really created by samba but instead created by the kernel, and then handed to smbd_t, should we even be doing a check?
We see this type of access in . cups.te:256:fs_rw_inherited_tmpfs_files(cupsd_t) mozilla.te:190:fs_rw_inherited_tmpfs_files(mozilla_t) mozilla.te:447:fs_rw_inherited_tmpfs_files(mozilla_plugin_t) openshift.te:235:fs_rw_inherited_tmpfs_files(openshift_domain) telepathy.te:409:fs_rw_inherited_tmpfs_files(telepathy_domain) thumb.te:82:fs_rw_inherited_tmpfs_files(thumb_t) virt.te:731:fs_rw_inherited_tmpfs_files(virt_domain) virt.te:1184:fs_rw_inherited_tmpfs_files(svirt_sandbox_domain)
12468771e2fcb51ec4b000d2fd7816d70e3ee40e allows this in selinux-policy git, but I think we should fix the kernel.
Perhaps I'm misunderstanding things, but even though the kernel created the shared memory segment, it is now being manipulated by userspace and as a result I'm fairly certain we want to keep enforcing access checks on the memory segment. In almost all cases I can think of where we sidestep the access checks on kernel created objects, the objects are non-persistent and only accessed from within the kernel, never userspace.
Then we should take into account the transitions, and whether or not the process is allowed to create the content. When the kernel is creating the object for smbd_t it should see if there is a transition and create the content as smbd_tmpfs_t or check if the process is allowed to create tmpfs_t, and fail with the AVC. Now e have lots of processes using tmpfs_t which seems to me to be labeled incorrectly.
I agree with Paul that this is a deifferent situation than kernel keyrings which are a completely opaque and internal feature of the kernel.
Well, unless I'm looking at the SHM hooks wrong, we do have an access control check upon SHM creation, 'shm:create', but we don't take into account any transitions. Does the policy currently support specifying transitions for shared memory? That said, if it is the kernel that is creating the shared memory segment I don't think a transition will help much since it will appear as 'kernel_t kernel_t shm:create'. Perhaps a better understanding of what samba is doing here will help - samba folks?
See details in comment #2. When samba is compiled with performance profiling support, it uses SHM segment to record performance counters from multiple smbd processes. This SHM segment needs to be accessible from smbd and smbcontrol utility.
*** Bug 1031896 has been marked as a duplicate of this bug. ***
Paul, My point here is that smbd and the others are just doing shm calls which should be controlled via shm access control, but here the kernel is creating a backing store (I think) on a tmpfs_t, called "/SYSV07021999 (DELETED)". Which should either be owned by the kernel_t or should use a file transition rule for smbd_t on tmpfs_t to label it something like smbd_tmpfs_t iff the file transition rule existed.
Dan, that makes sense. I was originally under the assumption that somehow the kernel was creating the shared memory area and handing it off to userspace; now that I understand the creation of the memory segment is initiated by userspace I agree that tmpfs_t probably isn't the correct label. Let me take a closer look at things (I'm not entirely sure yet why we are seeing tmpfs_t in a call to shmat()) and I'll get back to you. In the meantime I'll take ownership of this BZ.
Is there a smbd_t tmpfs_t:file type transition defined in policy? I do not see one in F19.
I know Dan was hoping that there would be a kernel solution to this, but after looking at things and talking about it with some other folks I've come to the realization that we need the SELinux access control checks on the shared memory backing store (look into how mprotect() is handled for the reasons why). Since there isn't anything we can do in the kernel, I'm reassigning this issue to the policy folks. Sorry guys.
*** This bug has been marked as a duplicate of bug 1033843 ***
Paul one concern I have about this, is we do not see an AVC for create or open on these. Meaning, I am not sure if the transition code will work. If I added code to have smbd_t create smbd_tmpfs_t on tmpfs_t directories.
create/open not required here. Transition will occur if you define type_transition in policy however; it is computed on the first d_instantiate() of the shmem/tmpfs dentry.
The transition has been already added.
After further discussion with Dan, Eric, and Miroslav today it sounds like there is some additional work needed to ensure that the kernel properly handles the type transition for shmem. I'm reopening this BZ to track this work.
Evidence that the kernel doesn't do the right thing, please? Because it always used to, and the code looks like it still will. shmem_file_setup() calls d_instantiate which calls security_d_instantiate() -> selinux_d_instantiate() -> inode_doinit_with_dentry() -> case SECURITY_FS_USE_TRANS -> security_transition_sid(). Done.
(In reply to Stephen Smalley from comment #24) > Evidence that the kernel doesn't do the right thing, please? > Because it always used to, and the code looks like it still will. > shmem_file_setup() calls d_instantiate which calls security_d_instantiate() > -> selinux_d_instantiate() -> inode_doinit_with_dentry() -> case > SECURITY_FS_USE_TRANS -> security_transition_sid(). Done. There was concern that shmget() was not eventually calling into the LSM and triggering a type transition, but as you point out, that doesn't appear to be the case. Dan, Miroslav, is the type transition rule correct?
Is the problem that /tmp and /dev/shm/ are labeled differently? Were the file trans rules written for tmp_t or tmpfs_t ? (/dev/shm is tmpfs_t and /tmp/ is tmp_t)
Currently we have a transition rule for smbd_t in Rawhide. Miroslav we should back port this to RHEL7/F20.
I just updated rawhide to remove all instances of fs_rw_tmpfs_file and replace calls with tmpfs transition rules. After doing this, I am wondering if we should just remove tmpfs_t versus tmp_t and treat them the same.
Which eric asked a couple of questions above. I will send an email to the refpolicy list to kick off the discussion of removing *tmpfs_t and alias to tmp_t.
(In reply to Daniel Walsh from comment #27) > Currently we have a transition rule for smbd_t in Rawhide. Miroslav we > should back port this to RHEL7/F20. We should have them also in F20/RHEL7.
Since we're back to dealing with this in policy, I'm reassigning this BZ.
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.