RFC: SELinux model

Jan Safranek jsafrane at redhat.com
Mon Apr 14 12:13:13 UTC 2014


On 04/11/2014 02:10 PM, Jan Synacek wrote:
> Hello,
> 
> I have finished the first version of the SELinux model for OpenLMI [1].
> 
> Suggestions and comments are welcome.

Jan, it's a great start. There are some rough edges here and there,
still it's the best CIM interface design OpenLMI has ever had.

Few comments:

- LMI_SELinuxBoolean:
  - suggestion: s/Currently set state/Current state/,
  - suggestion: s/State value that is set persistently across
reboots/State on next system boot/

- LMI_SELinuxBoolean: It should have a Description property, as shown by
'semanage boolean -l', SELinux might have API for that somewhere. And if
not, there is /usr/share/selinux/devel/policy.xml.


- LMI_SELinuxFile: we already have context and expected context as
properties of LMI_UnixFile, it does not seem appropriate to provide them
again in LMI_SELinuxFile (rendering LMI_SELinuxElementWithContext
practically useless...)
  - also, enumeration of this class must be disabled, which makes
creation of references pretty hard.


- LMI_SELinuxService.State: it must have Disabled value.

- LMI_SELinuxService: I would rename State and DefaultState to
SELinuxState and SELinuxDefaultState, it looks confusing to have
Enabled/EnabledDefault from CIM_Service and State and DefaultState for
SELinux.
  - The same for LMI_SELinuxService.Type... PolicyType? SELinuxPolicyType?

- LMI_SELinuxService.Type: is it possible to have any other policy than
Targeted/Minimum/MLS? Like a customer having its own policy, 'Unknown'
value would be appropriate here. Better ask some SELinux guru. What
policies do other distros ship?
  - suggestion: s/SELinux type/SELinux policy type/

- LMI_SELinuxService.PolicyVersion: is it really uint32? string might be
more appropriate.

- LMI_SELinuxService.SetState: it's not possible to set state on the
next boot without changing current SELinux state. E.g. this is not
possible: I want Enforcing on next boot, while staying Permissive for
now. It might be better to have SetState(uint16 NewState, uint16
NewDefaultState), where NULL would mean no change of the respective state.

- LMI_SELinuxService.SetState: What happens when e.g. runtime state
setting succeeds, but setting the default state fails? Caller then does
not know what's part of the operation succeeded/failed. Maybe have two
separate functions? Or can we expect that the applications are smart
enough to reload the actual state on failure? Some note in method
description would be appropriate.

- LMI_SELinuxService.SetPortLabel: it should accept port number as
string, in case someone wants to label a port, which is not yet in the
policy and thus there is no LMI_SELinuxPort for it. And it should accept
the string as range.

- LMI_SELinuxService.SetPortLabel: there should be a way how to remove a
label on a port, either in SetPortLabel or in separate method.

- LMI_SELinuxService.SetFileLabel: not sure if simple string would be
enough as Target... it's quite hard to get proper file reference.

- LMI_SELinuxService.GetMislabeledFiles(): It's not clear how the method
returns list of files. Some LMI_SELinuxFileJob + its association to
files is missing?

- LMI_SELinuxService.RestoreLabel: it should also export list of changes
it did, in the very same way as GetMislabeledFiles() should do. Maybe
there could be just one method with two modes - dry run / normal run?



- I am not sure about ports design. It's hard to say how a port will be
labelled, it's all hidden in strings with ranges. If it's just generic
overview of current policty then it's probably fine. I just have a gut
feeling it's too much low level and we may hit some limitation in the
future.

  - I am also not sure about its behavior, having let's say
snmp_port_t/tcp: 161-162, 199, 1161 and xserver_port_t/tcp: 6000-6020,
what happens if I label 1161 with xserver_port_t?
    - will it (silently, no indications) remove the port from
snmp_port_t and add it to xserver_port_t?
    - or it just adds 1161 to xserver_port_t, having the port with both
labels? (semanage allows that)
    - some note in the description would be appropriate

Jan


More information about the openlmi-devel mailing list