I am configuring sendmail authentication using cyrus-sasl on a Fedora 17 server. The server, when it goes live, will essentially run Apache and mail for a number of domains. I intend that selinux will run 'enforcing' with 'targeted' policy.
I have installed cyrus-sasl and initially test it as follows: Modify /etc/sysconfig/saslauthd MECH=pam -> MECH=shadow
[root@..]# systemctl restart saslauthd.service [root@..]# make reload [root@..]# setenforce 0 [root@..]# testsaslauthd -u foo -p foospwd 0: OK "Success."
OK saslauthd works, but I get selinux alerts, so:
[root@..]# grep saslauthd /var/log/audit/audit.log | audit2allow -M saslpol [root@..]# cat saslpol.te module saslpol 1.0 require {sasl_auth_t; class capability { sys_nice dac_read_search dac_override }; class process setsched; } allow saslauthd_t self capability { sys_nice dac_override dac_read_search }; allow saslauthd_t self process { setsched }
Which looks fine to my un-educated eyes. Before I semodule -i saslpol.pp, and taking seriously Bill McCarthys "evil" warning in his discussion of the use of audit2allow in the O'Reilly book.
I need to know what I'm doing, right?
Fundamentally I'm going to allow the process saslauthd access to /etc/shadow, which by definition is a potential security hole!
The following questions arise:
0 - I suppose the first question is: Should I be using some other authentication mechanism rather than shadow for saslauth? Historically I've avoided PAM, allowing only SSH server login using certificates. Therefore avoiding the PAM learning curve.
1 - Given that, in the short term, I am getting too old to fully understand the subtle depths and complexities of selinux! How far should I trust the resulting above saslpol.te?
2 - Is it possible to determine what other actions sys_nice, dac_read_search, dac_override get allowed for saslauthd?
3 - Should I test my saslpol is the minimum required? By for example, by including each capability targets one at a time and in combination, and testing the results at each step?
I hope that's not too many questions in one post. Thanks in advance, Charles Bradshaw
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/03/2013 09:38 AM, Charles Bradshaw wrote:
I am configuring sendmail authentication using cyrus-sasl on a Fedora 17 server. The server, when it goes live, will essentially run Apache and mail for a number of domains. I intend that selinux will run 'enforcing' with 'targeted' policy.
I have installed cyrus-sasl and initially test it as follows: Modify /etc/sysconfig/saslauthd MECH=pam -> MECH=shadow
[root@..]# systemctl restart saslauthd.service [root@..]# make reload [root@..]# setenforce 0 [root@..]# testsaslauthd -u foo -p foospwd 0: OK "Success."
OK saslauthd works, but I get selinux alerts, so:
[root@..]# grep saslauthd /var/log/audit/audit.log | audit2allow -M saslpol [root@..]# cat saslpol.te module saslpol 1.0 require {sasl_auth_t; class capability { sys_nice dac_read_search dac_override }; class process setsched; } allow saslauthd_t self capability { sys_nice dac_override dac_read_search }; allow saslauthd_t self process { setsched }
Which looks fine to my un-educated eyes. Before I semodule -i saslpol.pp, and taking seriously Bill McCarthys "evil" warning in his discussion of the use of audit2allow in the O'Reilly book.
I need to know what I'm doing, right?
Fundamentally I'm going to allow the process saslauthd access to /etc/shadow, which by definition is a potential security hole!
The following questions arise:
0 - I suppose the first question is: Should I be using some other authentication mechanism rather than shadow for saslauth? Historically I've avoided PAM, allowing only SSH server login using certificates. Therefore avoiding the PAM learning curve.
1 - Given that, in the short term, I am getting too old to fully understand the subtle depths and complexities of selinux! How far should I trust the resulting above saslpol.te?
2 - Is it possible to determine what other actions sys_nice, dac_read_search, dac_override get allowed for saslauthd?
3 - Should I test my saslpol is the minimum required? By for example, by including each capability targets one at a time and in combination, and testing the results at each step?
I hope that's not too many questions in one post. Thanks in advance, Charles Bradshaw
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
Have you tried the saslauthd_read_shadow boolean?
sesearch -A -C | grep saslauthd_read DT allow saslauthd_t shadow_t : file { ioctl read getattr lock open } ; [ saslauthd_read_shadow ] DT allow saslauthd_t etc_t : dir { ioctl read getattr lock search open } ; [ saslauthd_read_shadow ] DT allow saslauthd_t saslauthd_t : capability dac_override ; [ saslauthd_read_shadow ]
Hi Danial, Thanks for the quick reply.
Using SELinux Administration under Boolean reveals: Active Module Description sasl Allow sasl to read shadow I check Active for the above, restart saslauthd, but NO change: # testsalsauthd -u foo -p foospw 0: NO "authentication failed"
Your sugestioh: # sesearch -A -C | grep saslauthd_read ET allow saslauthd_t shadow_t : file { ioctl read getattr lock open } ; [ allow_saslauthd_read_shadow ] ET allow saslauthd_t etc_t : dir { ioctl read getattr lock search open } ; [ allow_saslauthd_read_shadow ]
My problem is essentially that I don't understand SELinux Administration GUI or the output from sesearch!
Why is the boolean not called allow_saslauthd_read_shadow in the GUI? Where is the doc for the meaning of output from sesearch?
On the other hand installing: module saslpol 1.1;
require { type saslauthd_t, shadow_t; class capability { sys_nice dac_read_search dac_override }; class process setsched; class file { read getattr open }; }
#============= saslauthd_t ============== allow saslauthd_t self:capability { sys_nice dac_override dac_read_search }; allow saslauthd_t self:process setsched; allow saslauthd_t shadow_t:file { read getattr open };
WORKS ( with the aforementioned sasl boolean unchecked).
BUT is this SAFE? and is it the minimum necessary access permissions?
I've added the last line in saslpol.te from examining audit.log and a second run of audit2allow recommendation! I got NO alerts in, either mode, using the version having no last line! Even after SELinux Administration GUI, 'Enabled Audit' for additional audit rules, that are normaly not reported in the log files.
Charles Bradshaw
################################### On: Thu, 03 Jan 2013 10:59:16 -0500 Daniel J Walsh wrote:
snippet: Have you tried the saslauthd_read_shadow boolean?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/03/2013 06:17 PM, Charles Bradshaw wrote:
Hi Danial, Thanks for the quick reply.
Using SELinux Administration under Boolean reveals: Active Module Description sasl Allow sasl to read shadow I check Active for the above, restart saslauthd, but NO change: # testsalsauthd -u foo -p foospw 0: NO "authentication failed"
Your sugestioh: # sesearch -A -C | grep saslauthd_read ET allow saslauthd_t shadow_t : file { ioctl read getattr lock open } ; [ allow_saslauthd_read_shadow ] ET allow saslauthd_t etc_t : dir { ioctl read getattr lock search open } ; [ allow_saslauthd_read_shadow ]
My problem is essentially that I don't understand SELinux Administration GUI or the output from sesearch!
Why is the boolean not called allow_saslauthd_read_shadow in the GUI? Where is the doc for the meaning of output from sesearch?
Man page. sesearch is reading the policy and showing you what is allowed -C means conditionally. The E Means it is enabled.
This means that the policy now allows allow saslauthd_t shadow_t:file { read getattr open };
I don't tend to use the GUI...
So you don't need this in your policy module.
rpm -q selinux-policy
On the other hand installing: module saslpol 1.1;
require { type saslauthd_t, shadow_t; class capability { sys_nice dac_read_search dac_override }; class process setsched; class file { read getattr open }; }
#============= saslauthd_t ============== allow saslauthd_t self:capability { sys_nice dac_override dac_read_search }; allow saslauthd_t self:process setsched; allow saslauthd_t shadow_t:file { read getattr open };
WORKS ( with the aforementioned sasl boolean unchecked).
BUT is this SAFE? and is it the minimum necessary access permissions?
I've added the last line in saslpol.te from examining audit.log and a second run of audit2allow recommendation! I got NO alerts in, either mode, using the version having no last line! Even after SELinux Administration GUI, 'Enabled Audit' for additional audit rules, that are normaly not reported in the log files.
Charles Bradshaw
################################### On: Thu, 03 Jan 2013 10:59:16 -0500 Daniel J Walsh wrote:
snippet: Have you tried the saslauthd_read_shadow boolean?
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
Judging whether or not something is safe is up to you. I would prefer that saslauthd used helper apps or the pam stack for reading /etc/shadow, but it does not, so if you choose to run saslauthd in the state that needs to read /etc/shadow, you neeed to five salsauthd this access.
The rules that you have given would allow a hacked saslauthd the ability to read /etc/shadow, ignore dac controls and change its priority. Ignoring DAC controls is not a huge problem, since SELinux would still control what it is allowed to read and write. Reading /etc/shadow, would potentially allow it to upload the /etc/shadow file somewhere or easily run a cracker on the password entries, which is why we try to prevent as many programs as possible from reading /etc/shadow.
selinux@lists.fedoraproject.org