After a few investigation during my freetime (SELInux is not part of
my work, for the moment, I hope ;p), here are some points about what I
said previously :
In the base modules, we have :
interface(`ldap_read_config',`
gen_require(`
type slapd_etc_t;
')
files_search_etc($1)
allow $1 slapd_etc_t:file { getattr read };
')
However, no module has the ldap_read_config rights (and no other
occurences of slapd_etc_t in the SELinux sources).
However, a ls -ZR | grep slapd_etc (on /) gives me
-rw-r----- root ldap system_u

bject_r:slapd_etc_t slapd.conf
-rw-r----- root root system_u

bject_r:slapd_etc_t slapd.conf.default
-rw-r----- root ldap system_u

bject_r:slapd_etc_t slapd.conf.tmp
So, if we use slapd_etc_t for pam ldap data, we would
allow accesses from
- slapd allowded domains to pam ldap configuration files
- pam ldap allowded domains to slapd configuration files
which are according to me not required authorization.
Best Regards.
-- Julien Thomas
PS: previous comment / questions are still relevant
Julien Thomas <julien.thomas@enst-bretagne.fr> a écrit :
Yes, you are right for the etc_t rules redundancy. I have added this for
several reasons such as
adding all the required rules if we consider the module as an
independent one, which means that is must be standalone. Thus, the
redundancy is present but may prevent possibly conflict in the future
(in the case of new domains adding)
The slapd_etc_t, if I'm not wrong, is not dedicated to pamldap but more
to LDAP server and LDAP in general (openldap, ... which do not need to
access this file) ?. So, adding a new type dedicated to pamldap
engenders a more precise confinement. But I can not check this for the
moment.
Otherwise, thanks for your greetings
If you want a policy rebuilding for reference policy style compliance,
please tell me (at least if you agree with my previous comments).
Julien Thomas
Chris PeBenito a écrit :
On Mon, 2007-11-19 at 01:13 +0100, julien.thomas@enst-bretagne.fr wrote:
The main aspect of this SELinux module consists in defining a new
domain for the
confinement of the PAMLDAP module. I have created this module as when
I used the
PamLDAP extension for remote authentications, I discovered that it used
sensitive information for LDAP connexions.
The module aims to protect these datas (security enhancement in order
to prevent to prevent root services from accessing these previously
etc_t labelled files).
Thanks for your submission. I especially appreciate the design document
you wrote. However, I don't think this particular action is required,
but another.
First, the specified domains already have access to etc_t, so these
rules are redundant. You suggest adding a type for the ldap.conf
because it has authentication data, which I agree with. However, the
ldap policy already has a type which might be appropriate for this file,
slapd_etc_t.
As for the style, the reference policy style is preferred. Please see
the website [1] for more details.
[1] http://oss.tresys.com/projects/refpolicy/wiki/GettingStarted
--
My RSA public key for email authentication is avaiblable at
http://www.rennes.enst-bretagne.fr/~jthomas2/
--
gentoo-hardened@gentoo.org mailing list