Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cachetool doesn't work out of the box with SELinux #9

Closed
ghost opened this issue Jan 15, 2015 · 8 comments
Closed

cachetool doesn't work out of the box with SELinux #9

ghost opened this issue Jan 15, 2015 · 8 comments

Comments

@ghost
Copy link

ghost commented Jan 15, 2015

You get a 404 on the fastgi response because it doesn't have the permission to read the cachetool generated file.

I'm not sure if this is really solvable without changing selinux configuration, but i do wonder if the stdin option of the fastcgi client would fix it.

Can you think of a quick hack to try that out?

@ghost ghost changed the title cachetool doesn't work out of the box with selinux cachetool doesn't work out of the box with SELinux Jan 15, 2015
@gordalina
Copy link
Owner

Permissions on the file are already set to 0666, which should be readable to everyone. Which OS and version are you using?

@ghost
Copy link
Author

ghost commented Jan 16, 2015

permissions aren't the only concern when using selinux, security contexts are.

I'm using fedora 21 with SELinux turned on, but i imagine this could also be replicated with Centos 7 or Fedora 20.

@gordalina
Copy link
Owner

I will have a look this weekend
On sex, 16/01/2015 at 00:22 Johnny Robeson notifications@github.com wrote:

permissions aren't the only concern when using selinux, security contexts
are.

I'm using fedora 21 with SELinux turned on, but i imagine this could also
be replicated with Centos 7 or Fedora 20.


Reply to this email directly or view it on GitHub
#9 (comment).

@gordalina
Copy link
Owner

Yeah, i guess without any custom configuration in selinux, this can't be avoided by cachetool.

@gordalina
Copy link
Owner

Closing this issue due to inactivity. Have you been able to make it work with SELinux?

@ghost
Copy link
Author

ghost commented Feb 2, 2015

i've set SELinux to permissive for now, i haven't had had time to deal with it yet.

@gordalina
Copy link
Owner

Ler me know if you find a fix for it.
On seg, 2/02/2015 at 20:53 Johnny Robeson notifications@github.com wrote:

i've set SELinux to permissive for now, i haven't had had time to deal
with it yet.


Reply to this email directly or view it on GitHub
#9 (comment).

@driskell
Copy link

Sorry - 5 years too late 😄

I hope the below helps others who stumble here. It's not so much that php-fpm doesn't have access, but that cachetool isn't running in the same domain as php-fpm. TLDR - you can compile and install an SELinux module to fix.

If you run cache tool from an unconfined domain (such as unconfined_t - which you are in when you SSH or run via Cron) - then when you run cache tool it will run in that domain. In this domain - the file that gets created in /dev/shm is created as user_tmp_t (even though parent is tmpfs_t - due to unconfined transition). PHP-FPM running as httpd_t can access that file because httpd_t domain can access user_tmp_t files. I think all processes can. So that interactions between your console and other domains work OK if they need to share temporary files.

However. If you run cache tool from some other context it might be confined. For example, cloud-init, is confined to the cloud_init_t domain, and is where I came across this. From this domain there is no transition from tmpfs_t to user_tmp_t so it remains as tmpfs_t.And thus, PHP-FPM running as httpd_t will be denied access as it cannot access tmpfs_t. You can see this in the audit logs (/var/log/audit/audit.log usually) by searching for denied. Note the target context (tcontext) is tmpfs_t.

type=AVC msg=audit(1607604349.443:185): avc:  denied  { getattr } for  pid=1387 comm="php-fpm" path="/dev/shm/cachetool-5fd2187d6bec01.03634697.php" dev="tmpfs" ino=27254 scontext=system_u:system_r:httpd_t:s0 tcontex
t=system_u:object_r:tmpfs_t:s0 tclass=file permissive=0

Fix for this is a module like follows. Just substitute the domain with the domain you are calling from. You can get the domain from the above audit entry from the scontext (source context).

policy_module(php-cachetool, 1.0.0);

require {
  type cloud_init_t;
  type httpd_t;
  type httpd_exec_t;
}

domain_auto_trans(cloud_init_t, httpd_exec_t, httpd_t)
allow httpd_t cloud_init_t:process sigchld;

Save the above as module-name.te inside a folder called module-name.
You may need to install packages to bring in the tooling (on CentOS it's policycoreutils-python and selinux-policy-devel)
Then compile, and also change your cachetool script to be httpd_exec_t. So when it runs - cachetool runs as httpd_t, and the tmp file it creates will become httpd_tmpfs_t and can be accessed by PHP-FPM.

cd module-name
# Compile
make -f /usr/share/selinux/devel/Makefile module-name.pp
# Install
semodule -i module-name.pp
# Change cachetool context
chcon -t httpd_exec_t /opt/cachetool.phar

(You can add the cachetool label to a file module-name.fc in the same place as the te if you Google the format of that file and the module will include it as a permanent label. Or you can use semanage fcontext to add it as a user configuration.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants