By default, the current ssh profile does not allow the creation of the agent socket required for agent functionality: Nov 15 04:39:42 testbed kernel: [161222.315988] audit: type=1400 audit(1416047982.585:3985): avc: denied { write } for pid=1655 comm="ssh" name="agent.1624" dev="tmpfs" ino=50218529 ipaddr=173.173.113.156 scontext=root:staff_r:ssh_t tcontext=system_u:object_r:sshd_tmp_t tclass=sock_file permissive=1 Since all sshd_tmp_t needs is the ability to create the socket, I've gone ahead and made up a fix. Now I can ssh -A without a policy denial. It won't survive the newrole transition but that's another issue. Further, I am highly disinclined to make this a boolean, as this is basic and accepted functionality that can be disabled on both client and server side without adding a selinux widget someone has to turn. Patch: diff --git a/policy/modules/services/ssh.te b/policy/modules/services/ssh.te index c5f585f..46331bd 100644 --- a/policy/modules/services/ssh.te +++ b/policy/modules/services/ssh.te @@ -111,6 +111,7 @@ allow ssh_t sshd_key_t:file read_file_perms; # Access the ssh temporary files. allow ssh_t sshd_tmp_t:dir manage_dir_perms; allow ssh_t sshd_tmp_t:file manage_file_perms; +manage_sock_files_pattern(ssh_t, sshd_tmp_t, sshd_tmp_t) files_tmp_filetrans(ssh_t, sshd_tmp_t, { file dir }) manage_files_pattern(ssh_t, ssh_tmpfs_t, ssh_tmpfs_t) Reproducible: Always
Can you elaborate on what you are doing? I use keychain to start the ssh agent. The ssh agent runs in the staff_ssh_agent_t domain and when I connect to servers (using ssh) the ssh agent does it work (i.e. no passphraze requests).
Nothing fancy. SSH to the server, and make agent support explicit. Eg, ssh -A $server The issue is valid but the fix is going to be more complicated. I fell asleep right after doing this last night and probably tested on the wrong terminal window. The patch itself is necessary for the agent socket to be written at all, but I think a more expansive solution is needed. Or something. The ssh subsystem has been untouched so you can consider this an adequate representation of what's going on with the current reference policy. The issue, expanded: 1) ssh -A in client side ssh will do the correct thing: debug1: Requesting authentication agent forwarding. debug1: Sending environment. ...presuming the overall ssh environment lets you. Mine does. 2) Check out the environment. ssh did do the right thing as a result of the patch: # set | grep SSH_AUTH_SOCK SSH_AUTH_SOCK=/tmp/ssh-5U1IlNbv4x/agent.7068 3) Now try to use it. testbed ~ # ls -Z /tmp/ssh-5U1IlNbv4x/agent.7068 ls: cannot access /tmp/ssh-5U1IlNbv4x/agent.7068: Permission denied testbed ~ # id -Z root:staff_r:staff_t Uhoh. This is the right result for *other* user's agents, but not mine! Looking at it via sysadm_r: # ls -Z /tmp/ssh-5U1IlNbv4x/agent.7068 system_u:object_r:sshd_tmp_t /tmp/ssh-5U1IlNbv4x/agent.7068 So there's a transition from sshd_tmp_t to whatever the user's actual context is that is missing. You can't setup an arbitrary interface to sshd_tmp_t because ALL user's agent sockets live there. But you say this works out of the box for you? Pinning this for later, I am currently battling LVM.
Still happening with 2.3, for the record. I'll figure something out later.
I never used SSH agent forwarding, but am glad to have read about it now ;) I can confirm and will be working on this.
Yes, granting read/write access seems to be ok: # Fix bug #529336 - Allow ssh_t to read/write sshd_tmp_t sockets (ssh agent forwarding) allow ssh_t sshd_tmp_t:sock_file rw_sock_file_perms; The SSH daemon should be creating a separate directory for every session. For instance, after logging in with the users user and oper: test tmp $ ls -lZ total 0 drwx------. 2 oper operators system_u:object_r:sshd_tmp_t:s0 60 Mar 4 17:37 ssh-gS2H5G2GRF drwx------. 2 user users system_u:object_r:sshd_tmp_t:s0 60 Mar 4 17:36 ssh-pzFSTtMbp5 The DAC permissions on the directory are solid. Regular users should not have direct access to the location, but their SSH client should: user@test ~ $ id uid=1000(user) gid=100(users) groups=100(users) context=user_u:user_r:user_t:s0 user@test ~ $ ls -lZ ${SSH_AUTH_SOCK} ls: cannot access /tmp/ssh-pzFSTtMbp5/agent.17904: Permission denied user@test ~ $ ssh -T git@github.com Hi sjvermeu! You've successfully authenticated, but GitHub does not provide shell access. Exiting the sessions also clears the temporary locations. Fix is in repository, will be part of rev 4
Now in repo, ~arch
r4 is stable
