FAS and public Key auth

[brett lentz]

On Thu, May 22, 2008 at 6:31 AM, Mike McGrath <mmcgrath at redhat.com> wrote:
> On Wed, 21 May 2008, brett lentz wrote:
>
>> On Wed, May 21, 2008 at 9:06 PM, Mike McGrath <mmcgrath at redhat.com> wrote:
>> That said, that doesn't mean we should ignore potential risk from
>> blindly trusting third party systems. I would recommend that, at a
>> minimum, third party systems should run with selinux on and enforcing.
>> This would afford some additional assurance of the system's security,
>> but won't solve all problems.
>>
>
> But how would this protect us in any way if the users of that system had
> root on it?  Since all of these 3rd part systems aren't officially
> monitored by us we have to assume the worst on each of these hosts.
>

That's why I said it won't solve all problems. The scenarios where
selinux helps are when root is not yet compromised, it helps reduce
the risk of things like privilege escalation and exploiting holes in a
public facing application to gain shell access.

Unfortunately, the current selinux policies will not stop someone
accessing an existing shell account and sudoing their way to root.

This is where I think we need to work up some requirements for third
party systems. We need some level of assurance that the admins of that
system have some sane security policies and are maintaining them. It
shouldn't be difficult to work up a script or set of scripts to
periodically audit the third party systems to assure that these
policies are adhered to.

IMO, a good starting point for those requirements would be:

1. system runs Fedora/RHEL
2. system has selinux enabled and enforcing.
3. system uses an acceptable update schedule.
4. system's admins are known, and willing to be available when we need
to contact them (within a reasonable set of hours)
5. the system's admins document their policy for providing root access
to their system. this allows us to do some risk analysis.
6. we should be able to quickly and easily revoke the system's access to Fedora.


>> > Now, I've never actually done this.  It's just my understanding that it'd
>> > work that way.  If you had root on a box and I sshed there with my ssh
>> > key, would you not have access to take the key and log in to other boxes
>> > as me?
>> >
>>
>> I'm not a crypto guy by any stretch. But, my understanding is that no,
>> that's not how it public key authentication should work. As I
>> understand it, your private key is never sent across the wire and
>> therefore even with root on the remote system, an attacker could only
>> ever has access to your public key. This is assuming that your private
>> key isn't also in your home directory on the remote system (i.e. the
>> only local file they have is the authorized_keys). Please double-check
>> RFC 4252 for more details.
>>
>> > So my question is, is this a real risk or is there a precaution in SSH
>> > preventing the attack i'm describing (basically a man in the middle type
>> > attack)
>> >
>>
>> I think the mitm risk is fairly low. I think there are other risks,
>> such as not having direct control over keeping third party systems up
>> to date, or allowing third party systems running non-Fedora or
>> non-RHEL distros (e.g. the latest Debian openssh debacle). Privilege
>> escalation on the remote system is also a concern. Thankfully, selinux
>> can mitigate the last fairly effectively.
>>
>> I definitely don't think this should be done lightly.
>>
>
> You think mitm is fairly low but is it really?  Lets say, for example, you
> forward your ssh agent to this remote host.  What are the implications
> there?

The implications for ssh-agent is fairly simple. Your private key
still never touches the wire or the remote systems. SSH-Agent forwards
the auth challenges to the local system you're logging in from.

Here's a great diagram of the process:
http://www.unixwiz.net/techtips/ssh-agent-forwarding.html#fwd



>        -Mike
>

---Brett.