Bug 1389628 - selinux context changed by cron
Summary: selinux context changed by cron
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: acme-tiny
Version: el6
Hardware: Unspecified
OS: Unspecified
low
unspecified
Target Milestone: ---
Assignee: Stuart D Gathman
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-10-28 04:31 UTC by Stuart D Gathman
Modified: 2020-04-10 16:59 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-04-10 16:59:45 UTC
Type: Bug


Attachments (Terms of Use)

Description Stuart D Gathman 2016-10-28 04:31:57 UTC
Description of problem:
cron renews certs, but selinux context is changed to cron_var_lib_t

Version-Release number of selected component (if applicable):
acme-tiny-0.1-10.git5a7b4e7.el6.noarch

How reproducible:
always

Steps to Reproduce:
1. add an acme cert
2. wait for it to renew (adjust /etc/cron.d/acme-tiny to shorten time)
3.

Actual results:
New file context of certs is 
-rw-r--r--. acme acme system_u:object_r:cron_var_lib_t:s0 wiki.crt

Expected results:
-rw-r--r--. acme acme system_u:object_r:var_lib_t:s0   wiki.crt

Additional info:
Running restorecon -rv /var/lib/acme/certs restores the context of the certs.  How does cron accomplish this trick, anyway?

Comment 1 Stuart D Gathman 2016-10-28 16:04:56 UTC
crond runs as crond_t, and the policy for that says that any files created as var_lib_t become cron_var_lib_t instead.  Voila.  (But why?)

So labeling /var/lib/acme/certs as cert_t as suggested in the README avoids the problem.  I think we need acme-tiny-selinux to label the dir.

Another way is to create a /etc/pki/acme directory (which would be cert_t) and symlink to it.  But some users require no updates to /etc during normal operation. (Which makes the whole /etc/pki directory problematic.)

Comment 2 Japheth Cleaver 2017-10-29 21:27:36 UTC
(In reply to Stuart D Gathman from comment #1)

> Another way is to create a /etc/pki/acme directory (which would be cert_t)
> and symlink to it.  But some users require no updates to /etc during normal
> operation. (Which makes the whole /etc/pki directory problematic.)

I can see how it would make the directory problematic, but that's more of a distro-level issue than anything else. For the task acme-tiny is used for, something in /etc/pki/ really does seem like the most correct function. An override could be available for those that need a read-only /etc. 

Likely, "normal operation" isn't really what acme-tiny is intended as, as it does change security arrangements in some manner. A sysadmin in a ro-/etc/ environment probably already has a mechanism for dealing with cases when it needs to become rw (patch cycles and the like), and a script like this would seem to fall into that well.

Comment 3 Stuart D Gathman 2017-10-29 21:48:32 UTC
Thanks for that feedback.  I need to make a release targeting bz#1438181 (split out acme-tiny-core with just the upstream script).  That would be a good time to add the symlink.

But how would I handle upgrading existing installations?

Comment 4 Stuart D Gathman 2017-11-22 17:56:01 UTC
This problem doesn't seem to happen using the systemd timer, and EL6 is nearing EOL.  So this is low priority.

Comment 5 Stuart D Gathman 2020-04-10 16:59:45 UTC
EL6 is near EOL, so this is going to be a WONTFIX.


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