Bug#697814: [DSE-Dev] Bug#697814: selinux-policy-default: exim4 and bitlbee want access to sysctl_crypto_t

[Marius Gavrilescu]

On Thu, Jan 10, 2013 at 02:59:41AM +0100, Mika Pflüger wrote:
 How should we proceed? Add kernel_read_crypto_sysctls for everyone who
 needs it (which could be quite some list considering that libgrypt11
 has about 200 reverse dependencies…) or follow the fedora way and allow
 it for everybody?

Allowing everyone to read it seems reasonable. There's no security problem
if a program finds out whether we are in fips mode or not.

 However, this only breaks fips mode for the affected programs so maybe
 the impact is so low that we don't fix it for wheezy and therefore
 only work for a solution upstream. How many people use system wide fips
 mode?

I don't use fips mode, but I think that fips users[0] would want this bug
fixed in wheezy. The change is minor, so getting an unblock wouldn't be
difficult. An actual fips user[0] should say their opinion on this bug.

[0]: if there are any
-- 
Marius Gavrilescu
(kids) There's no one in there. --6 year old son, in response to seeing his 
father hanging pictures and tapping on the walls to find the support beams.


signature.asc
Description: Digital signature

Bug#697814: [DSE-Dev] Bug#697814: selinux-policy-default: exim4 and bitlbee want access to sysctl_crypto_t

[Mika Pflüger]

Hi,

Am Thu, 10 Jan 2013 00:11:17 +0200
schrieb Marius Gavrilescu mar...@ieval.ro:
 For some reason exim4 and bitlbee are trying to read
 /proc/sys/crypto/fips_enabled and SELinux doesn't let them.

Seems to me they are using libgcrypt which tries to
read /proc/sys/crypto/fips_enabled to determine if it should enable
fips mode. Most applications are however not allowed to do so, in
debian atm only
chkpwd_t, rpm_t, rpm_script_t, puppet_t, puppetmaster_t
are allowed access via the kernel_read_crypto_sysctls interface
(defined in kernel.if). In latest upstream git there are quite some
additional types which are allowed access, but exim4 and bitlbee are not
among those.
fedora adds
kernel_read_crypto_sysctls(domain)
which will allow this for a /lot/ of other programs, basically
everybody (for example bitlbee and exim, which are init_daemon_domain).
As (at least on my system) there is only the fips_enabled file
in /proc/sys/crypto, the possible harm from allowing this for everybody
seems very small. It is only the information if the system is in fips
mode.

How should we proceed? Add kernel_read_crypto_sysctls for everyone who
needs it (which could be quite some list considering that libgrypt11
has about 200 reverse dependencies…) or follow the fedora way and allow
it for everybody?

However, this only breaks fips mode for the affected programs so maybe
the impact is so low that we don't fix it for wheezy and therefore
only work for a solution upstream. How many people use system wide fips
mode?


Cheers,

Mika

-- 



signature.asc
Description: PGP signature