CODEWITHSUNDEEP
ruby-on-railsrubyapachecentosselinux
Conan Morris
Conan Morris

Reputation: 133

SELinux type getting set incorrectly for files uploaded VIA a Rails application

So I have a web application running on Centos 6.5.

The application is a Ruby/Rails app, but the images are served by Apache HTTPD.

The application folder is in a user home folder, but I've granted HTTPD the correct permissions, and have enabled httpd_enable_home_dirs within SELinux. All static images are working just fine.

The problem I am seeing is when an end user uploads an image (A profile icon), the SELinux context for the file is getting set to unconfined_u:object_r:user_tmp_t:s0 instead of unconfined_u:object_r:usr_t:s0.

If I manually run restorcon on the file, the context gets fixed, and the image works. Any idea how I can make sure the file gets created with the correct context? I've looked into using restorcond, but it looks like it won't recursively check subdirectories, and the subdirectory structure is not predictable.

Any help is appreciated.

Upvotes: 2

Views: 499

Answers (2)

dac.override
dac.override

Reputation: 56

Most likely your application is moving 'mv' the object from /tmp, or /var/tmp to the destination location.

By default when a object is moved with 'mv', then so is its security metadata. Thus the object ends up at the destination with old and inaccurate security metadata. Running 'restorecon' on the destination objects resets the contexts to what the policy thinks it should be.

There are various ways you can deal with this. Either allow your webapp to read the object with the inaccurate context or tell your webapp to either use 'mv' with the -Z option, or use 'cp' instead. (the 'cp' command copies the object, and as a consequence the target object ends up with the appropriate security metadata, usually mostly inherited from the targets parent directory.

Upvotes: 4

Conan Morris
Conan Morris

Reputation: 133

So apparently SELinux suppresses some error messages...

In order to debug this I had to run

semodule -DB

This rebuilds/restarts the local policy with the disable "don't log" flag. Once "don't log" is disabled, the error messages show up in the audit log and you can add a new policy using the regular:

sealert -a /var/log/audit.log

Then find the audit2allow command for the error in question.

You can set your logging back to normal after by running

semodule -B

Upvotes: 0

Related Questions