With selinux-*-9999 policies a normal user cannot run SSH. Reproducible: Always Steps to Reproduce: 1.Install sec-policy/selinux-*-9999 2. Login as normal user (no role changes) while system is enforcing strict 3. Try to ssh to another system Actual Results: alunduil@selinux ~ $ 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: Audit log: type=AVC msg=audit(1349546929.695:392): avc: denied { search } for pid=1481 comm="ssh" name="ssl" dev="xvda1" ino=32802 ipaddr=72.191.11.121 scontext=alunduil_u:staff_r:ssh_t tcontext=system_u:object_r:cert_t tclass=dir Expected Results: Working outgoing ssh connections as regular users. audit2allow -R suggests the following modification to ssh_t due to the addition of cert_t: miscfiles_read_generic_certs(ssh_t) I have added the above as a localssh policy and it does fix the issue: alunduil@selinux ~ $ ssh giskard.alunduil.com Password:
Can you (safely ;) show the ssh client & server configuration? I can't reproduce this, and the "Auto configuration failed" message seems somewhat weird. Not that I don't think it's needed, but I'd like to know when it is needed in case I have to "defend" it upstream.
It's a mostly stock set of configs (I've attached them for your review). I'm not sure why it's auto-configuring either. Like I said this is pretty stock. Let me know if the configs help or if you need anything else. These are the configs from the system I'm SSH'ing _from_ (the one exhibiting this behavior).
Created attachment 325842 [details] /etc/ssh/sshd_config
Created attachment 325844 [details] /etc/ssh/ssh_config
So it's because (open)ssh links with libcrypto, offered by openssl. And that part wants to read the openssl.cnf file.
Upstreamed: http://oss.tresys.com/pipermail/refpolicy/2012-October/005845.html Cause of the failure is a commit from the Debian folks to label /etc/ssl as cert_t completely (whereas it previously was etc_t). Two ways can be used to handle this. (1.) Allow ssh_t to read generic certificates, as you suggested. Since it is because ssh linked with libcrypto, this is not a weird suggestion, and imo doesn't impact security. (2.) Label /etc/ssl and /etc/ssl/openssl.cnf as etc_t, and use cert_t for /etc/ssl/certs* and other I submitted the first one upstream, but if the second option is better we'll use that.
Well, upstream found that openssl.cnf should remain etc_t, but the second patch on that hasn't been committed upstream (just silence). I assume it'll be done though, so I already committed it to our repository. Should be in the live ebuilds available already, and in r6 when it comes out.
In hardened-dev, r6 release
In main tree, ~arch'ed
