Skip to contentSkip to conversation

Allow ssh to read cert_t files

PATCH New Sven Vermeulen 4 participants 6 messages Oct 11, 2012 – Oct 19, 2012

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 Allow ssh to read cert_t files

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.

---
 policy/modules/services/ssh.te |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
policy/modules/services/ssh.te +1 -0
index b17e27a..4826400 100644
@@ -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)
Signature · 1 line
1.7.8.6
#1 lore raw

PATCH 1/1 Allow ssh to read cert_t files

Quoted 4 lines · Sven Vermeulen

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.

Quoted 30 lines

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.

---
 policy/modules/services/ssh.te |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
policy/modules/services/ssh.te +1 -0
index b17e27a..4826400 100644
@@ -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)
Signature · 3 lines
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com
#2 lore raw

PATCH 1/1 Allow ssh to read cert_t files

Quoted 7 lines · Christopher J. PeBenito
Quoted 4 lines · Sven Vermeulen

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
Quoted 32 lines
Quoted 30 lines

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.

---
 policy/modules/services/ssh.te |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
policy/modules/services/ssh.te +1 -0
index b17e27a..4826400 100644
@@ -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)
#3 lore raw

PATCH 1/1 Allow ssh to read cert_t files

Quoted 7 lines · Dominick Grift
Quoted 2 lines

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

Quoted 8 lines
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

#4 lore raw

PATCH 1/1 Allow ssh to read cert_t files

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

Quoted 24 lines · Sven Vermeulen
Quoted 6 lines · Dominick Grift
Quoted 2 lines

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

Quoted 7 lines

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)

Quoted 8 lines

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

#5 lore raw

PATCH 1/1 Allow ssh to read cert_t files

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

Quoted 2 lines

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