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 1298192 - BUG: SELinux conditional policies are ignored for userspace object managers
Summary: BUG: SELinux conditional policies are ignored for userspace object managers
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 23
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Paul Moore
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1263328 1298597 1298607 1298816 1299034 1299117 1300531 1301007 1301327 1306104 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-01-13 12:40 UTC by Andrea Bolognani
Modified: 2016-02-28 16:21 UTC (History)
58 users (show)

Fixed In Version: kernel-4.3.3-303.fc23
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-01-26 18:24:04 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Andrea Bolognani 2016-01-13 12:40:07 UTC
Description of problem:

  Since the last kernel update, crond has been unable to access my
  user's crontab.

  The journal contains these messages, wrapped for convenience:

    Jan 13 12:40:01 pandorica crond[1305]:
      (abologna) Unauthorized SELinux
      context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
      file_context=unconfined_u:object_r:user_cron_spool_t:s0
      (/var/spool/cron/abologna)

    Jan 13 12:40:01 pandorica crond[1305]:
      (abologna) FAILED (loading cron table)

  This is the relevant crontab:

    -rw-------. 1 abologna abologna
    unconfined_u:object_r:user_cron_spool_t:s0
    181 Jan 13 12:39
    /var/spool/cron/abologna

  and this is the crond process:

    system_u:system_r:crond_t:s0-s0:c0.c1023
    root 1305 1  0 08:59 ?  00:00:00
    /usr/sbin/crond -n

  Booting with the previous kernel is enough to make crond access
  the user's crontab again.


Version-Release number of selected component (if applicable):

  kernel-4.3.3-300.fc23.x86_64
    - affected kernel version

  kernel-4.2.8-300.fc23.x86_64
    - previous kernel version

  cronie-1.5.0-3.fc23.x86_64
  libselinux-2.4-4.fc23.i686


How reproducible:

  100%


Steps to Reproduce:

  1. Boot the system with the latest kernel
  2. Check the journal


Actual results:

  crond is unable to access the user's crontab


Expected results:

  crond picks up the user's crontab


Additional info:

  None

Comment 1 Josh Boyer 2016-01-13 13:46:40 UTC
Have you tried relabeling?  This looks very much like an SELinux issue, not something kernel specific.

Comment 2 Andrea Bolognani 2016-01-13 14:04:02 UTC
I have tried relabeling, to no avail. I have also tried, while running
the latest kernel, creating a new user and adding a job to that user's
crontab. That didn't work either.

I'm not sure what the culprit might be: I have reported this against
the kernel because, among the involved components (kernel, libselinux,
cronie) it's the only one that's been recently updated, and because
booting with an older kernel is an effective workaround. Feel free to
reassign it if you're positive recent changes in the kernel are not
the cause of this issues.

Comment 3 Paul Moore 2016-01-13 14:07:06 UTC
I can't think of any SELinux changes in the kernel's 4.3 release that would affect cron ... I'm CC'ing mgrepl in case he can think of anything; I suspect this may be a labeling and/or policy issue.

FWIW, I just looked on my Rawhide system, and the reporters crontab does appear to be labeled correctly.

Comment 4 Doug Herr 2016-01-14 16:58:40 UTC
Glad I found this.  I was about to give up on SELinux.

This morning I realized that crontab jobs were not running for either root or my user (the only two that had crontabs).

# uname -a
Linux wombat.wombatz.com 4.3.3-300.fc23.x86_64 #1 SMP Tue Jan 5 23:31:01 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

Please let me know if there is any other input you might need.

Comment 5 James Derrick 2016-01-14 19:07:24 UTC
Me too.

Spotted two new issues in logwatch, then a search found this bug. Cron jobs for root and my user both don't run.
 --------------------- Cron Begin ------------------------ 

 **Unmatched Entries**
 Unauthorized SELinux context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 file_context=unconfined_u:object_r:user_cron_spool_t:s0 (/var/spool/cron/myuser)
 FAILED (loading cron table)
 Unauthorized SELinux context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 file_context=unconfined_u:object_r:user_cron_spool_t:s0 (/var/spool/cron/root)
 FAILED (loading cron table)
  ---------------------- Cron End ------------------------- 

# ls -Z /var/spool/cron/root
unconfined_u:object_r:user_cron_spool_t:s0 /var/spool/cron/root

# uname -a
Linux foo 4.3.3-300.fc23.x86_64 #1 SMP Tue Jan 5 23:31:01 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

Comment 6 Benjamin Xiao 2016-01-14 19:20:49 UTC
I can confirm that going back to 4.2.8 works around the issue.

Comment 7 GMS 2016-01-14 20:00:32 UTC
Yes. While crontab -l gives the crontab content from "before", crontab
is not working for any of the users. The messages are as already described,
going back to last version before 4.3.3 "solves" the problem.

audit2allow/audit2why do not see any problems.

Comment 8 John Saalwaechter 2016-01-14 20:40:02 UTC
IMO, this should be set to the highest priority/severity.  Silently breaking cron jobs is a major problem.

Comment 9 Miroslav Grepl 2016-01-15 09:12:53 UTC

*** This bug has been marked as a duplicate of bug 1263328 ***

Comment 10 Josh Boyer 2016-01-15 13:57:30 UTC
*** Bug 1298816 has been marked as a duplicate of this bug. ***

Comment 11 Miroslav Grepl 2016-01-15 14:25:48 UTC
Paul,
the problem is with tunable policy - booleans.

We have 

(allow unconfined_t user_cron_spool_t( file ( entrypoint)))

as a part of tunable rule. If I allow it directly it works. We see it also for another use cases - dbus+sssd.

Is it possible it is caused by kernel? It looks there is no issue with policy here.

Comment 12 Miroslav Grepl 2016-01-15 14:34:44 UTC
Paul,
it also works if I downgraded kernel.

Comment 13 Miroslav Grepl 2016-01-15 14:36:47 UTC
*** Bug 1263328 has been marked as a duplicate of this bug. ***

Comment 14 Miroslav Grepl 2016-01-15 14:37:25 UTC
*** Bug 1298607 has been marked as a duplicate of this bug. ***

Comment 15 Robert Hancock 2016-01-15 23:53:52 UTC
Also seeing this in kernel-4.3.3-300.fc23.x86_64. Cron jobs are not functioning.

Comment 16 Doug Maxey 2016-01-16 18:45:58 UTC
dogpile.  :-) yes, seeing this also

Comment 17 André Martins 2016-01-17 00:29:52 UTC
*** Bug 1299117 has been marked as a duplicate of this bug. ***

Comment 18 dan 2016-01-18 05:27:38 UTC
Seeing this also on kernel 4.3.3-300.fc23.x86_64.  Noticed user crons had stopped running.

Jan 18 00:24:01 ears.private crond[16071]: (dan) Unauthorized SELinux context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 file_context=unconfined_u:object_r:user_cron_spool_t:s0 (/var/spool/cron/dan)
Jan 18 00:24:01 ears.private crond[16071]: (dan) FAILED (loading cron table)
Jan 18 00:24:13 ears.private crontab[17432]: (dan) REPLACE (dan)
Jan 18 00:24:13 ears.private crontab[17432]: (dan) END EDIT (dan)
Jan 18 00:25:01 ears.private crond[16071]: (dan) Unauthorized SELinux context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 file_context=unconfined_u:object_r:user_cron_spool_t:s0 (/var/spool/cron/dan)
Jan 18 00:25:01 ears.private crond[16071]: (dan) FAILED (loading cron table)

Comment 19 Miroslav Grepl 2016-01-18 08:06:35 UTC
Guys,
could you try to apply the following workaround

$ cat mycron.cil
(allow unconfined_t user_cron_spool_t( file ( entrypoint)))

and run

# semodule -i mycron.cil

and reload crond. It works for others.

Comment 20 Tomas Mraz 2016-01-18 09:04:39 UTC
*** Bug 1299034 has been marked as a duplicate of this bug. ***

Comment 21 Petr Pisar 2016-01-18 10:20:38 UTC
*** Bug 1298597 has been marked as a duplicate of this bug. ***

Comment 22 John Horne 2016-01-18 10:36:02 UTC
(In reply to Miroslav Grepl from comment #19)
> Guys,
> could you try to apply the following workaround
> 
> $ cat mycron.cil
> (allow unconfined_t user_cron_spool_t( file ( entrypoint)))
> 
> and run
> 
> # semodule -i mycron.cil
> 
> and reload crond. It works for others.
>
Yes, this worked for me. Cron jobs are now running.

Comment 23 Paul Moore 2016-01-18 14:23:09 UTC
My apologies for not thinking about this sooner, thanks to mgrepl for pointing out the problem with the conditional policy, that's the clue ... the fix should be the following patch, which was marked for stable but hasn't hit the F23 kernels yet for some reason (at least as of kernel-4.3.3-301.fc23).  The commit below should fix the problem:

  commit f3bef67992e8698897b584616535803887c4a73e
  Author: Stephen Smalley <sds.gov>
  Date:   Mon Nov 23 16:07:41 2015 -0500

    selinux: fix bug in conditional rules handling
    
    commit fa1aa143ac4a ("selinux: extended permissions for ioctls")
    introduced a bug into the handling of conditional rules, skipping the
    processing entirely when the caller does not provide an extended
    permissions (xperms) structure.  Access checks from userspace using
    /sys/fs/selinux/access do not include such a structure since that
    interface does not presently expose extended permission information.
    As a result, conditional rules were being ignored entirely on userspace
    access requests, producing denials when access was allowed by
    conditional rules in the policy.  Fix the bug by only skipping
    computation of extended permissions in this situation, not the entire
    conditional rules processing.
    
    Reported-by: Laurent Bigonville <bigon>
    Signed-off-by: Stephen Smalley <sds.gov>
    [PM: fixed long lines in patch description]
    Cc: stable.org # 4.3
    Signed-off-by: Paul Moore <pmoore>

You should be able to run any 4.4 based kernel, including current Rawhide or pcmoore/kernel-secnext kernels, and the cron problem should be resolved.  Please try one of the newer kernels and let me know if you are still seeing the problem, if so we'll work to get the patch backported to F23.

 * https://copr.fedoraproject.org/coprs/pcmoore/kernel-secnext

Comment 24 Andrea Bolognani 2016-01-18 14:52:31 UTC
I'm running

  kernel-4.5.0-0.rc0.git1.1.fc24.x86_64

installed from rawhide and the issue with cron is indeed no longer
present. The pcmoore/kernel-secnext repository did not work for me,
but let me know if I can help with further testing.

Comment 25 Petr Pisar 2016-01-18 14:53:43 UTC
I confirm kernel-4.3.3-301.fc23 is broken, kernel-4.4.0-1.fc24 with the same F23 user space is fixed for me. The at jobs work again.

Comment 26 Paul Moore 2016-01-18 15:33:28 UTC
(In reply to Andrea Bolognani from comment #24)
> The pcmoore/kernel-secnext repository did not work for me, but let me know if I 
> can help with further testing.

Slightly unrelated to this BZ, but can you explain what went wrong, did you follow the instructions on the page?

Comment 27 Josh Boyer 2016-01-18 16:02:02 UTC
The patch has been added in Fedora git.  It will be in the next build.

Comment 28 Andrea Bolognani 2016-01-18 16:28:35 UTC
(In reply to Paul Moore from comment #26)
> (In reply to Andrea Bolognani from comment #24)
> > The pcmoore/kernel-secnext repository did not work for me, but let me know if I 
> > can help with further testing.
> 
> Slightly unrelated to this BZ, but can you explain what went wrong, did you
> follow the instructions on the page?

Yup, here's what I did:

  $ sudo dnf copr enable pcmoore/kernel-secnext

  You are about to enable a Copr repository. Please note that this
  repository is not part of the main Fedora distribution, and quality
  may vary.

  The Fedora Project does not exercise any power over the contents of
  this repository beyond the rules outlined in the Copr FAQ at
  <https://fedorahosted.org/copr/wiki/UserDocs#WhatIcanbuildinCopr>, and
  packages are not held to any quality or security level.

  Please do not file bug reports about these packages in Fedora
  Bugzilla. In case of problems, contact the owner of this repository.

  Do you want to continue? [y/N]: y
  Repository successfully enabled.

  $ sudo dnf update
  Failed to synchronize cache for repo 'pcmoore-kernel-secnext' from
  'https://copr-be.cloud.fedoraproject.org/results/pcmoore/kernel-secnext/fedora-23-x86_64/':
  Cannot download repomd.xml: Cannot download repodata/repomd.xml:
  All mirrors were tried, disabling.

I see now that the packages are only built for rawhide, so of course
looking for the F23 repository couldn't work :)

Comment 29 Paul Moore 2016-01-18 16:49:52 UTC
(In reply to Andrea Bolognani from comment #28)
> I see now that the packages are only built for rawhide, so of course
> looking for the F23 repository couldn't work :)

Yes, that would be the problem :)  I was afraid something else was wrong.  Thanks for giving it a try and reporting back.

Comment 30 Daniel 2016-01-18 21:12:51 UTC
(In reply to Andrea Bolognani from comment #24)
> I'm running
> 
>   kernel-4.5.0-0.rc0.git1.1.fc24.x86_64
> 
> installed from rawhide and the issue with cron is indeed no longer
> present. The pcmoore/kernel-secnext repository did not work for me,
> but let me know if I can help with further testing.

Compiled 4.5.0-0.rc0.git1.1.fc23.x86_64 today and can confirm that the cron issue is no longer present.

# sestatus 
SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   enforcing
Mode from config file:          enforcing
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Max kernel policy version:      30

Tested all services and they seem to work normally. The cron table is loaded and all cron jobs are executed normally.

Comment 31 Charlie MacDonald 2016-01-19 11:36:32 UTC
I can confirm kernel 4.3.3.302.fc23 works on my systems and also resolves a SATA issue that cropped up on them after the update to 4.3.3.300.fc23 as well.

Comment 32 Fedora Update System 2016-01-19 12:53:52 UTC
kernel-4.3.3-302.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-db9fedd7c4

Comment 33 Fedora Update System 2016-01-20 21:57:54 UTC
kernel-4.3.3-303.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-b59fd603be

Comment 34 Fedora Update System 2016-01-22 04:57:42 UTC
kernel-4.3.3-303.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-b59fd603be

Comment 35 Petr Lautrbach 2016-01-22 10:41:06 UTC
*** Bug 1301007 has been marked as a duplicate of this bug. ***

Comment 36 dan 2016-01-23 11:33:13 UTC
kernel-4.3.3.303.fc23 install on x86_64, cron problem appears to be resolved.

Comment 37 Petr Lautrbach 2016-01-24 16:44:14 UTC
*** Bug 1301327 has been marked as a duplicate of this bug. ***

Comment 38 Fedora Update System 2016-01-26 18:21:35 UTC
kernel-4.3.3-303.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.

Comment 39 Tomas Mraz 2016-02-10 10:03:02 UTC
*** Bug 1306104 has been marked as a duplicate of this bug. ***

Comment 40 Miroslav Grepl 2016-02-12 08:55:53 UTC
*** Bug 1300531 has been marked as a duplicate of this bug. ***

Comment 41 David 2016-02-16 02:50:11 UTC
I am new to SELinux but have been using Fedora since 16.
Currently using in permissive mode and SELinux gave errors for /var/spool/cron/username as follows:

SELinux:  Context system_u:object_r::s0 is not valid (left unmapped).

After implementing the fix in comment 19 SELinux does not have errors but I get messages from crond as:

NULL security context for user, but SELinux in permissive mode, continuing ()

Is this as it should be or do I need to do something in addition to the fix in comment 19?

Thanks, 

David

Comment 42 Paul Moore 2016-02-16 20:51:33 UTC
(In reply to David from comment #41)
> I am new to SELinux but have been using Fedora since 16.
> Currently using in permissive mode and SELinux gave errors for
> /var/spool/cron/username as follows:
> 
> SELinux:  Context system_u:object_r::s0 is not valid (left unmapped).
> 
> After implementing the fix in comment 19 SELinux does not have errors but I
> get messages from crond as:
> 
> NULL security context for user, but SELinux in permissive mode, continuing ()
> 
> Is this as it should be or do I need to do something in addition to the fix
> in comment 19?

I would suggest filing a new BZ for your problem as it appears to be unrelated to this issue discussed here.


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