[gpfsug-discuss] GPFS and SELinux

Aaron Knister aaron.s.knister at nasa.gov
Thu Aug 11 05:47:17 BST 2016


Hi Everyone,

I'm passing this along on behalf of one of our security guys. Just 
wondering what feedback/thoughts others have on the topic.


Current IBM guidance on GPFS and SELinux indicates that the default
context for services (initrc_t) is insufficient for GPFS operations.

See:
https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/General+Parallel+File+System+(GPFS)/page/Using+GPFS+with+SElinux


That part is true (by design), but IBM goes further to say use runcon
out of rc.local and configure the gpfs service to not start via init.

I believe these latter two (rc.local/runcon and no-init) can be
addressed, relatively trivially, through the application of a small
selinux policy.

Ideally, I would hope for IBM to develop, test, and send out the policy,
but I'm happy to offer the following suggestions. I believe "a)" could
be developed in a relatively short period of time. "b)" would take more
time, effort and experience.

a) consider SELinux context transition.

As an example, consider:
https://github.com/TresysTechnology/refpolicy/tree/master/policy/modules/services


(specifically, the ssh components)

On a normal centOS/RHEL system sshd has the file context of sshd_exec_t,
and runs under sshd_t

Referencing ssh.te, you see several references to sshd_exec_t in:
domtrans_pattern
init_daemon_domain
daemontools_service_domain
(and so on)

These configurations allow init to fire sshd off, setting its runtime
context to sshd_t, based on the file context of sshd_exec_t.

This should be duplicable for the gpfs daemon, altho I note it seems to
be fired through a layer of abstraction in mmstartup.

A simple policy that allows INIT to transition GPFS to unconfined_t
would go a long way towards easing integration.

b) file contexts of gpfs_daemon_t and gpfs_util_t, perhaps, that when
executed, would pick up a context of gpfs_t? Which then could be mapped
through standard SELinux policy to allow access to configuration files
(gpfs_etc_t?), block devices, etc?

I admit, in b, I am speculating heavily.



-- 
Aaron Knister
NASA Center for Climate Simulation (Code 606.2)
Goddard Space Flight Center
(301) 286-2776



More information about the gpfsug-discuss mailing list