On 12/19/19 9:49 AM, Christian Göttsche wrote:
Am Mi., 18. Dez. 2019 um 21:05 Uhr schrieb Stephen Smalley <sds@xxxxxxxxxxxxx>:
On 12/18/19 9:28 AM, Christian Göttsche wrote:
Add new SELinux permissions `modify` and `listdynusers` to the class `service`.
- modfiy checks altering operations, like `systemctl log-level debug` or `systemctl add-wants foo bar`.
- listdynusers checks obtaining dynamic users, which is very common on systems using nss-systemd.
Add a new permission to avoid undermining the `status` permission.
Perform SELinux access checks for the following D-Bus exposed methods:
D-Bus interface | c function name | SELinux permission verb
GetAfter / GetBefore | bus_job_method_get_waiting_jobs | status
LogTarget | property_set_log_target | modify
LogLevel | property_set_log_level | modify
RuntimeWatchdocUSec | property_set_runtime_watchdog | modify
ServiceWatchdogs | bus_property_set_bool_wrapper | modify
GetUnit | method_get_unit | status
GetUnitByPID | method_get_unit_by_pid | status
GetUnitByControlGroup | method_get_unit_by_control_group | status
LoadUnit | method_load_unit | status
ListUnitsByNames | method_list_units_by_names | status
LookupDynamicUserByName | method_lookup_dynamic_user_by_name | listdynusers
LookupDynamicUserByUID | method_lookup_dynamic_user_by_uid | listdynusers
GetDynamicUsers | method_get_dynamic_users | listdynusers
AddDependencyUnitFiles | method_add_dependency_unit_files | modify
GetUnitFileLinks | method_get_unit_file_links | status
Unref | bus_unit_method_unref | modify
If we are going to introduce new permissions or change existing ones, we
may want to consider just defining a separate permission for every
logical interface. Then we can let the policy writer decide what
matters to them and at what granularity they want to distinguish things,
using macros/interfaces as appropriate to avoid needing to specify them
all individually.
Also, you may want to leverage the policy capability mechanism in
userspace to permit compatible evolution of permission checks in the
same manner it is presently used in the kernel for
extended_socket_class, network_peer_controls, open_perms,
nnp_nosuid_transition, etc.
This might be an idea, to preserve full backward compatibility.
While on it one could untangle the system security class.
Afaik this would require a SELinux userland and kernel update, to
introduce a new policy capability identifier?
Correct. I'd like to relax that requirement in the future (see
https://github.com/SELinuxProject/selinux/issues/55) but for now you
need a patched libsepol and a patched kernel. This would be the first
policy capability used by userspace instead of the kernel, so we'd also
need/want libselinux functions for testing whether a given policy
capability is enabled via selinuxfs. People with existing kernels or
policies would continue to operate with the old permission checks; it
would require an upgrade of libsepol, kernel, and a policy that
explicitly enables the new policy capability to cause the new permission
checks to take effect.
