With commit e5c59868be8fbca2d56c74d3418aff56344cc9fd, the /etc/ssl location (and
all files therein) are marked cert_t instead of etc_t. As this location contains
/etc/ssl/openssl.cnf, applications linked with openssl's libcrypto fail to
function properly.
The ssh client is one of those applications, which - if not granted - fails
with:
$ ssh giskard.alunduil.com
Auto configuration failed
118260437468864:error:0200100D:system library:fopen:Permission denied:bss_file.c:169:fopen('/etc/ssl/openssl.cnf','rb')
118260437468864:error:2006D002:BIO routines:BIO_new_file:system lib:bss_file.c:174:
118260437468864:error:0E078002:configuration file routines:DEF_LOAD:system lib:conf_def.c:199:
Allow ssh to read generic certs. An alternative would be to keep /etc/ssl as
etc_t (same with openssl.cnf) and label the subdirectories as cert_t.
Signed-off-by: Sven Vermeulen <[email protected]>
---
policy/modules/services/ssh.te | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/policy/modules/services/ssh.te b/policy/modules/services/ssh.te
index b17e27a..4826400 100644
--- a/policy/modules/services/ssh.te
+++ b/policy/modules/services/ssh.te
@@ -156,6 +156,7 @@ logging_read_generic_logs(ssh_t)
auth_use_nsswitch(ssh_t)
+miscfiles_read_generic_certs(ssh_t)
miscfiles_read_localization(ssh_t)
seutil_read_config(ssh_t)
--
1.7.8.6
On 10/11/12 14:45, Sven Vermeulen wrote:
> With commit e5c59868be8fbca2d56c74d3418aff56344cc9fd, the /etc/ssl location (and
> all files therein) are marked cert_t instead of etc_t. As this location contains
> /etc/ssl/openssl.cnf, applications linked with openssl's libcrypto fail to
> function properly.
I think what makes more sense to to make sure /etc/ssl/openssl.cnf is still labeled etc_t, since its a config file, not a cert.
> The ssh client is one of those applications, which - if not granted - fails
> with:
>
> $ ssh giskard.alunduil.com
> Auto configuration failed
> 118260437468864:error:0200100D:system library:fopen:Permission denied:bss_file.c:169:fopen('/etc/ssl/openssl.cnf','rb')
> 118260437468864:error:2006D002:BIO routines:BIO_new_file:system lib:bss_file.c:174:
> 118260437468864:error:0E078002:configuration file routines:DEF_LOAD:system lib:conf_def.c:199:
>
> Allow ssh to read generic certs. An alternative would be to keep /etc/ssl as
> etc_t (same with openssl.cnf) and label the subdirectories as cert_t.
>
> Signed-off-by: Sven Vermeulen <[email protected]>
> ---
> policy/modules/services/ssh.te | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/policy/modules/services/ssh.te b/policy/modules/services/ssh.te
> index b17e27a..4826400 100644
> --- a/policy/modules/services/ssh.te
> +++ b/policy/modules/services/ssh.te
> @@ -156,6 +156,7 @@ logging_read_generic_logs(ssh_t)
>
> auth_use_nsswitch(ssh_t)
>
> +miscfiles_read_generic_certs(ssh_t)
> miscfiles_read_localization(ssh_t)
>
> seutil_read_config(ssh_t)
>
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
On Fri, 2012-10-19 at 08:11 -0400, Christopher J. PeBenito wrote:
> On 10/11/12 14:45, Sven Vermeulen wrote:
> > With commit e5c59868be8fbca2d56c74d3418aff56344cc9fd, the /etc/ssl location (and
> > all files therein) are marked cert_t instead of etc_t. As this location contains
> > /etc/ssl/openssl.cnf, applications linked with openssl's libcrypto fail to
> > function properly.
>
> I think what makes more sense to to make sure /etc/ssl/openssl.cnf is still labeled etc_t, since its a config file, not a cert.
Maybe, but in /etc/pki/tls is the same issue and there it is also
labeled cert_t
ls -alZ /etc/pki/tls
drwxr-xr-x. root root system_u:object_r:cert_t:s0 .
drwxr-xr-x. root root system_u:object_r:cert_t:s0 ..
lrwxrwxrwx. root root system_u:object_r:cert_t:s0 cert.pem ->
certs/ca-bundle.crt
drwxr-xr-x. root root system_u:object_r:cert_t:s0 certs
drwxr-xr-x. root root system_u:object_r:cert_t:s0 misc
-rw-r--r--. root root system_u:object_r:cert_t:s0 openssl.cnf
drwxr-xr-x. root root system_u:object_r:cert_t:s0 private
> > The ssh client is one of those applications, which - if not granted - fails
> > with:
> >
> > $ ssh giskard.alunduil.com
> > Auto configuration failed
> > 118260437468864:error:0200100D:system library:fopen:Permission denied:bss_file.c:169:fopen('/etc/ssl/openssl.cnf','rb')
> > 118260437468864:error:2006D002:BIO routines:BIO_new_file:system lib:bss_file.c:174:
> > 118260437468864:error:0E078002:configuration file routines:DEF_LOAD:system lib:conf_def.c:199:
> >
> > Allow ssh to read generic certs. An alternative would be to keep /etc/ssl as
> > etc_t (same with openssl.cnf) and label the subdirectories as cert_t.
> >
> > Signed-off-by: Sven Vermeulen <[email protected]>
> > ---
> > policy/modules/services/ssh.te | 1 +
> > 1 files changed, 1 insertions(+), 0 deletions(-)
> >
> > diff --git a/policy/modules/services/ssh.te b/policy/modules/services/ssh.te
> > index b17e27a..4826400 100644
> > --- a/policy/modules/services/ssh.te
> > +++ b/policy/modules/services/ssh.te
> > @@ -156,6 +156,7 @@ logging_read_generic_logs(ssh_t)
> >
> > auth_use_nsswitch(ssh_t)
> >
> > +miscfiles_read_generic_certs(ssh_t)
> > miscfiles_read_localization(ssh_t)
> >
> > seutil_read_config(ssh_t)
> >
>
>
On Fri, Oct 19, 2012 at 02:53:44PM +0200, Dominick Grift wrote:
> > I think what makes more sense to to make sure /etc/ssl/openssl.cnf
> > is still labeled etc_t, since its a config file, not a cert.
>
> Maybe, but in /etc/pki/tls is the same issue and there it is also
> labeled cert_t
>
> ls -alZ /etc/pki/tls
> drwxr-xr-x. root root system_u:object_r:cert_t:s0 .
> drwxr-xr-x. root root system_u:object_r:cert_t:s0 ..
> lrwxrwxrwx. root root system_u:object_r:cert_t:s0 cert.pem ->
> certs/ca-bundle.crt
> drwxr-xr-x. root root system_u:object_r:cert_t:s0 certs
> drwxr-xr-x. root root system_u:object_r:cert_t:s0 misc
> -rw-r--r--. root root system_u:object_r:cert_t:s0 openssl.cnf
> drwxr-xr-x. root root system_u:object_r:cert_t:s0 private
I don't have /etc/pki here, but from the looks of it, it's exactly what
/etc/ssl is here:
~$ ls /etc/ssl
certs misc openssl.cnf private
So, it makes more sense to use something like
/etc/ssl/certs/*\.pem -- gen_context(system_u:object_r:cert_t,s0)
and same for /etc/pki? Then the remainder stays etc_t. Perhaps it makes
sense for /etc/ssl/private as well, but I'll need some more feedback on the
potential content of /etc/ssl/private to confirm.
Wkr,
Sven Vermeulen
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 10/19/2012 08:59 AM, Sven Vermeulen wrote:
> On Fri, Oct 19, 2012 at 02:53:44PM +0200, Dominick Grift wrote:
>>> I think what makes more sense to to make sure /etc/ssl/openssl.cnf is
>>> still labeled etc_t, since its a config file, not a cert.
>>
>> Maybe, but in /etc/pki/tls is the same issue and there it is also labeled
>> cert_t
>>
>> ls -alZ /etc/pki/tls drwxr-xr-x. root root system_u:object_r:cert_t:s0
>> . drwxr-xr-x. root root system_u:object_r:cert_t:s0 .. lrwxrwxrwx.
>> root root system_u:object_r:cert_t:s0 cert.pem ->
>> certs/ca-bundle.crt drwxr-xr-x. root root system_u:object_r:cert_t:s0
>> certs drwxr-xr-x. root root system_u:object_r:cert_t:s0 misc
>> -rw-r--r--. root root system_u:object_r:cert_t:s0 openssl.cnf
>> drwxr-xr-x. root root system_u:object_r:cert_t:s0 private
>
> I don't have /etc/pki here, but from the looks of it, it's exactly what
> /etc/ssl is here:
>
> ~$ ls /etc/ssl certs misc openssl.cnf private
>
> So, it makes more sense to use something like
>
> /etc/ssl/certs/*\.pem -- gen_context(system_u:object_r:cert_t,s0)
>
> and same for /etc/pki? Then the remainder stays etc_t. Perhaps it makes
> sense for /etc/ssl/private as well, but I'll need some more feedback on
> the potential content of /etc/ssl/private to confirm.
>
> Wkr, Sven Vermeulen _______________________________________________
> refpolicy mailing list refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
>
I would rather then default be certs and then special case the cnf files.
Since users will be copying in files into this directory.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iEYEARECAAYFAlCBiqUACgkQrlYvE4MpobMkqQCeKY3Nl+WtIbD1DL/xj5oohKlS
YsMAnRPr5SFJY67BoTJfoo31Ti0Qe0gd
=kt5J
-----END PGP SIGNATURE-----
On Fri, Oct 19, 2012 at 01:15:17PM -0400, Daniel J Walsh wrote:
[... About marking certs/private as cert_t and let the rest remain etc_t ...]
> I would rather then default be certs and then special case the cnf files.
> Since users will be copying in files into this directory.
Most of the time, users will be copying files into the certs folder, not? I
see no purpose in files inside /etc/ssl (but not in a subdirectory) to be
labeled as cert_t.
Either you copy certificates in the certs/ folder, or you copy keys in the
private/ folder.
My previous patch only labels files, not the directory itself. Okay if I
update the patch to mark /etc/{ssl,pki}/certs and /etc/{ssl,pki}/private as
cert_t (regardless of type)?
That way, files copied inside of it automatically inherit the cert_t type.
Wkr,
Sven Vermeulen