[gpfsug-discuss] GPFS and SELinux

Jan-Frode Myklebust janfrode at tanso.net
Thu Aug 11 10:54:27 BST 2016


I believe the runcon part is no longer necessary, at least on my RHEL7
based systems mmfsd is running unconfined by default:

[root at 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 <aaron.s.knister at nasa.gov>
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20160811/76b704e3/attachment.htm>


More information about the gpfsug-discuss mailing list