I believe the runcon part is no longer necessary, at least on my RHEL7 based systems mmfsd is running unconfined by default:
[root@flexscale01 ~]# ps -efZ|grep mmfsd unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 18018 17709 0 aug.05 ? 00:24:53 /usr/lpp/mmfs/bin/mmfsd and I've never seen any problems with that for base GPFS. I suspect doing a proper selinux domain for GPFS will be quite close to unconfined, so maybe not worth the effort... -jf On Thu, Aug 11, 2016 at 6:47 AM, Aaron Knister <[email protected]> wrote: > 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 > _______________________________________________ > gpfsug-discuss mailing list > gpfsug-discuss at spectrumscale.org > http://gpfsug.org/mailman/listinfo/gpfsug-discuss >
_______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
