FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora SELinux Support

 
 
LinkBack Thread Tools
 
Old 06-26-2011, 01:33 PM
Matthew Ife
 
Default SSSD Local Auth and SELinux support

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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 06-26-2011, 06:20 PM
Genes MailLists
 
Default SSSD Local Auth and SELinux support

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).


Slightly OT for selinux but it sounds very very useful - but don't we
lose the ability of the simple and rather wonderful ability to edit the
password / group files (e.g. appending a standard user set to the
password files). What is the sssd alternative for this?



--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 06-26-2011, 06:21 PM
Genes MailLists
 
Default SSSD Local Auth and SELinux support

On 06/26/2011 02:20 PM, Genes MailLists wrote:

>
> Slightly OT for selinux but it sounds very very useful -

I meant my post is OT .. :-)

--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 06-27-2011, 10:26 AM
Daniel J Walsh
 
Default SSSD Local Auth and SELinux support

-----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@lists.fedoraproject.org
> 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/

iEYEARECAAYFAk4IWuAACgkQrlYvE4MpobNCgwCgt7c8M9GSBn BkAoC683Ozs/8O
KocAoINGdd7cG3zeL7w6gk3dhv6gFP4m
=0rQ2
-----END PGP SIGNATURE-----
--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 06-30-2011, 10:47 PM
Matthew Ife
 
Default SSSD Local Auth and SELinux support

Heres a patch I built in main policy for F15 that removes macros using
except_shadow and replaces them with except_auth_file.

It adds a new attribute declared in authlogin.te called
"authentication_file_type" and a new macro in files.te called
"files_authentication_file" to add the attribute for the file.

shadow_t has an authentication_file_type.

Dont *think* I broke anything with this patch.

My git skills are poor but this diff produces the changes I had made.
--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 07-05-2011, 04:23 PM
Daniel J Walsh
 
Default SSSD Local Auth and SELinux support

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/30/2011 06:47 PM, Matthew Ife wrote:
> Heres a patch I built in main policy for F15 that removes macros using
> except_shadow and replaces them with except_auth_file.
>
> It adds a new attribute declared in authlogin.te called
> "authentication_file_type" and a new macro in files.te called
> "files_authentication_file" to add the attribute for the file.
>
> shadow_t has an authentication_file_type.
>
> Dont *think* I broke anything with this patch.
>
> My git skills are poor but this diff produces the changes I had made.
>
>
>
> --
> selinux mailing list
> selinux@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/selinux
Please send this patch to upstream refpolicy.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk4TOm0ACgkQrlYvE4MpobNBXACg1LL+RejIfh FyjU9VTJO7t+/O
rtQAoMuLRjQ5yr2m+I0BS8gz7ROo073x
=Z3Mm
-----END PGP SIGNATURE-----
--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 

Thread Tools




All times are GMT. The time now is 06:33 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org