-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 06/26/2011 09:33 AM, Matthew Ife wrote:
> 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
This sounds Legitimate and I would be willing to look at a patch. I
have been removing other access because of sssd also.
http://danwalsh.livejournal.com/42186.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk4IWuAACgkQrlYvE4MpobNCgwCgt7c8M9GSBnBkAoC683Ozs/8O
KocAoINGdd7cG3zeL7w6gk3dhv6gFP4m
=0rQ2
-----END PGP SIGNATURE-----
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux
