14 comments on “splunk and selinux

  1. This may never happen. It really needs to run unconfined, there aren’t any rules for moving from a targeted policy to unconfined_t.

    This stemmed from needing to filter out reads of audit.log by splunk, which just filled everything up. We added the following rule:

    -a exit,always -F dir=/var/log/audit -F perm=wa -F arch=b64 -S open -k LOG -k audit

    This made it so that only writes or attribute changes got logged, not reads. We really are only interested in unauthorized changes. This has significantly reduced our audit logging.

  2. Was able to implement a splunk type by adding:

    unconfined_domain(splunk_t)

    at the bottom of the splunk.te, then added an audit rule to filter out -F subj_type=splunk_t

  3. Hi riffraff169,

    We are trying to solve a similar problem, except our PCI auditors want any reads to the audit.log file to also be logged. So your first comment about changing the audit rule to ignore reads does not help us. So just to clarify… you managed to get the above splunk.te file to work by adding
    unconfined_domain(splunk_t)
    before:
    consoletype_exec(splunk_t)
    ?
    What does your full audit rule become?

  4. The full audit rule becomes:

    -A exit,never -F obj_type=auditd_log_t -F subj_type=splunk_t

    Since only splunk reads it as splunk_t, that is the only time that access to audit.log doesn’t get logged. Since we knew audit.log was being read by splunk, and that was allowed, we stopped it from logging it, because it filled up our splunk logs and used a lot of bandwidth between the server, the splunk forwarders, and the final splunk machine.

    Now you can add a -p r to it so that it will log “wa” (writes and attribute changes), and filter out reads.

    Again, this is only for the splunk process, everyone else gets logged still.

    The unconfined_domain(splunk_t) selinux rule doesn’t tell it to become the domain “unconfined”, which is the name of a domain that is unconfined, but it makes splunk_t an unconfined domain along with the domain “unconfined” (kind of confusing, I know).

  5. Also, I presume you are running splunk as root, or splunk will not be able to read the audit.log file? (chown’s do not persist after file rotates.) Have you edited the splunk init script at all? It seems that the way it is written, it runs by default as:
    subj=user_u:system_r:unconfined_t:s0
    which is indistinguishable from someone su’d to root (and whose reads of the audit.log file I would want to log).

    • Well, the splunk selinux module creates a new context for it, so it is running under splunk_t:

      # ps auwwxZ|grep splunk
      system_u:system_r:splunk_t:s0 root 6250 0.4 0.1 516420 67396 ? Sl Feb08 125:46 splunkd -p 8089 start
      system_u:system_r:splunk_t:s0 root 6251 0.0 0.0 50508 7468 ? Ss Feb08 2:46 splunkd -p 8089 start

      However, it has to run unconfined because it runs a lot of external programs, some of which have their own contexts (ntpdate, rpm, ifconfig, etc), and I would have to define a type transition for every single program it runs. Others run unconfined themselves anyway (top), and would have to have another type transition. I was running into more and more problems with that. It could be done, it was just so involved, and I had other priorities, so I made it unconfined. It actually runs unconfined normally, I just created a separate type for it.

      I could add my rules (audit and splunk) as separate files that are more easily downloaded.

  6. BTW, it looks like a badly written init script to me, or at least not the Redhat way. The other init scripts start binaries using daemon, presumably part of /etc/rc.d/init.d/functions. Splunk just starts the binary as a user would (hence why it gets the same SELinux context. Other services ( get things like:
    root:system_r:initrc_t:s0
    or:
    system_u:system_r:initrc_t:s0
    (where some more specific domain has not been configured)

    • Well, the init script is actually ok. They usually only do the daemon function if the program they are calling doesn’t background itself, so the daemon function uses runuser with & to background it. The splunk binary does, so daemon isn’t necessary.

      From what I’ve researched, if a process started by init doesn’t have it’s own context, it runs as initrc_t. If it does, it gets transitioned to its own type.

      If you look in the policy source (for RHEL5, serefpolicy-2.4.6), directory policy/modules, you can see the policy modules for a lot of services. There are also a bunch in policy/apps (and other dirs in policy). They will define all the types and transitions. It has been very helpful to look through those files. If you are interested in selinux policies, that is a great resource. The RHEL6 policy source has even more stuff in it.

  7. Any updates on this? It has really helped me to get an idea of how to do a Splunk
    policy.

    Thank you.

    • Probably better than what I have. I’ll look and see if it covers everything, although I’m sure mine doesn’t. I haven’t maintained mine in a bit, though, so it is probably more recent at least.

      • The “SELinux Policy for Splunk” seems to work well in distributed Splunk environments with apps that do various things. Having said that, I’d like the Splunk community to provide as much feedback as possible to refine it before submitting to rawhide. Early on I wasn’t even sure Splunk was a reasonable candidate for confinement with TE because even in the absence of custom apps, it touches so many parts of a system in so many different ways (as you well know). Conversely, Splunk is actually the perfect candidate for confinement, because it almost always has to be run as root to collect the inputs it’s given (without dirty hacks). The goal of this policy was essentially to let Splunk “read” anything on the system, but prevent it from making changes to either its core binaries/libraries or anything else on the system.

        I’ve recently added interfaces to this policy then used them to create a Splunk admin role, so that users can be given root access via sudo using a role that only allows them to administer Splunk as root but nothing else. This will be committed to the git repo soon.

        See you at .conf? 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s