Bug 1389628

Summary:	selinux context changed by cron
Product:	[Fedora] Fedora EPEL	Reporter:	Stuart D Gathman <stuart>
Component:	acme-tiny	Assignee:	Stuart D Gathman <stuart>
Status:	CLOSED WONTFIX	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	low
Version:	el6	CC:	cleaver-redhat, stuart
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-04-10 16:59:45 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:

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.