2

I want to run logstash as root to allow it to read all logs (granting it access to every log is very tiresome). However, I don't want it running amok on my server, I thought about constraining it under SELinux.
The options I see are:

  • Create an entire new label for logstash. This also means creating labels for logstash config files, logstash executables and libraries, etc.
  • Run logstash using a label designed for another process. I put my eye on clogd_t since it has log in its name and I couldn't find any suspicious write permissions using sudo sesearch --allow -s clogd_t | grep clogd_t | less -p write
  • Give up and run it as an unconstrained root process

Is either a normal thing to do?

In case it matters, I'm using CentOS 6.7

Nitz
  • 1,038
  • 1
  • 8
  • 18

1 Answers1

3

I would rather make a custom policy because it's cleaner and makes you in control of what is happening.

Custom policy

As I understand it is a java-based daemon which you will be running so probably is sensible to make it run as system_u:system_r:logstash_t. Then you will need to give (read only?) access to all the log files to the logstash_t domain and finally grant any additional permissions logstash may require to run.

Using the refpolicy interfaces we have something like:

policy_module(logstash, 1.0)

# define the entry point and the domain
type logstash_exec_t
init_daemon_domain(logstash_t, logstash_exec_t)

Then the logstash daemon need to be able to read log files:

logging_search_all_logs(logstash_t)
logging_getattr_all_logs(logstash_t)
logging_read_all_logs(logstash_t)

This should do most of the job, then you'll need to add the rest.

Reused policy

For what is concerning the second point I am not sure why you are not getting any write permission reported by sesearch but if you look at the sources:

# clogd.te
storage_raw_read_fixed_disk(clogd_t)
storage_raw_write_fixed_disk(clogd_t)

# storage.te 
########################################
## <summary>
##      Allow the caller to directly write to a fixed disk.
##      This is extremely dangerous as it can bypass the
##      SELinux protections for filesystem objects, and
##      should only be used by trusted domains.
## </summary>
## <param name="domain">
##      <summary>
##      Domain allowed access.
##      </summary>
## </param>
#
interface(`storage_raw_write_fixed_disk',`
# and the rest of the stuff here...

Not really what one would want from a logging monitoring tool. You may find something suitable to be used with the second solution, just make really sure that you are not getting extra unneeded permissions as this defeats the whole purpose of running the process inside selinux.

Hope it helps.

qwattash
  • 131
  • 3
  • Thanks! Where did you find all of these macros? Weird I didn't see the writes in the `sesearch` thingy. – Nitz Oct 08 '15 at 05:24
  • When you write a policy you will see that 3 files can be used: my.if, my.fc and my.te. *.if files define the "interface" for each policy module and allow you to easily use other parts of the refpolicy without having to know all the details. Almost every module have an interface file and although you can find the [docs](http://oss.tresys.com/docs/refpolicy/api/) I would recommend having a look at the [sources](https://github.com/TresysTechnology/refpolicy) as well, just because you learn so much from it. – qwattash Oct 08 '15 at 10:31