First a breif explanation of what SSSD is doing in case people are
unfamiliar/
SSSD is a security services daemon. Its main purpose is to provide a
single abstraction layer for handling various name and authentication
services which previously would be done through individual configuration
entries (such as krb5.conf or ldap.conf).
One of the most promising features is the use of a local authentication
provider. This is somewhat a reinvention of shadow/passwd/group files in
a single database managed through sssd but has a significant advantage;
authentication and password alteration is done by-proxy of the sssd
daemon meaning applications do not require read/write access to the sssd
database files. You can still of course use traditional auth methods
using PAM.
Implementation is done using a series of user and group userland
equivalents to the stuff found in shadow-utils (sss_useradd,
sss_groupmod etc) which make direct changes to the databse files that
sssd uses at the back.
An interesting aspect I can see to SSSD Local services is that I can now
cheaply and logically segregate system users from non-system users,
which I would prefer to do. This in turn allows the system to manage
system related users in passwd and non-system related ones can be left
to the sysadmin to do using the sss_* management utilities. This should
hopefully make the shadow file almost redundant, offering only password
storage for root and not exposing every other user on the system.
Another big advantage from an implementation end is sss databases
require far less access throughout the system, rather all requests are
via a single source (sssd) which other services hook into by-proxy using
PAM. This reduces the scope of access a typical operating system needs
to give to be able to manage non-system users. From a quick check I did
database entries from SSSD would require read access from only 12
domains whereas shadow requires 29 subjects.
Firstly, SELinux offers very little support for sss local databases
treating them like standard sssd_var_lib folders, this provides 33
domains (some of which are clearly unnecessary like mplayer and
rgmanager) read access to these files. Fair enough - so I go about
adding an extra restricted type of sssd called sssd_db_t which would
manage the database files for sss services.
I mark the sssd_db type as a security_file_type, when I then compare it
to what shadow shows (which is also a security file) there are less
domains that can read this file than can for sssd_db types. Whats the
crack?
Well - the issue here is that in main policy - there exists a macro
auth_read_all_(files|dirs)_except_shadow which implements an all files
type without shadow being permitted.
Herein lies my problem. Firstly, SSS is an optional module. Monolithic
should be as lean as possible. But nature of this macro is it does:
allow domain { files_type -shadow_t }:file read_file_perms
Currently in refpolicy its impossible to have another file type put in
there thats from an optional module!
This problem means I can never get sss restricted down to the same as
shadow (without marking the file as shadow which gives sssd access to
the shadow file which I DONT want to do!). In fact I could give it even
less scope than that but its not possible in refpolicy.
One way around this however, is to change the macros in refpolicy so it
becomes something more like:
interface(`auth_read_all_files_except_auth_file',`
gen_require(`
attribute authentication_file;
')
files_read_all_files_except($1, $2 -authentication_file)
')
In refpolicy we declare attribute shadow_t as a authentication_file.
Then for future policy writers who consider their file shadow-like in
security they can go:
typeattribute my_secure_t authentication_file;
(or of course provide a wrapper module that performs the same task)
To get the same effect as a shadow file at very little effort.
This is a somewhat core change to policy as shadow_t will be one of
these types that have had a lot of thought put into their access
control. I want to know if people think I am thinking too far ahead here
or not.
Personally - I see a lot of promise with sss and local. It means I can
prevent rpm/dpkg from messing with my legit users on a system by doing
something daft. And services like sasl, smbd or passwd wont need access
to it directly either reducing access scope for my users. Plus my shadow
file ends up containing no passwords in it! (lock root, use sudo)
Albeit, I wont want to use it going forward myself until I can get some
assurance its at least as secure from the O/S level as shadow is.
Something which at the moment is impossible.
Thoughts, insights and alternatives to my problem are much appreciated!
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux
