[ale] Sessions question

[leam hall]

Ah, so a new SSH connection gets a new PID, no matter where it's from. And
a pseudo-tty. So a man in the middle, if they could decrypt the session
information, could hijack the login session. Does this sound reasonably
convincing?

>From an OS session perspective, everyone logging in gets a unique shell
process. If a person logs in a second time to the same machine they are
given another shell process. Session IDs (SIDs) are related to the Process
ID (PID). Since the machine is running an arbitrary number of "things" at
any one time it would be difficult for an attacker to guess a SID and force
the ssh connection to establish and associate a PID where none existed
before because all "things" on the server create and consume PIDs. Further,
the packet capturing vector may be difficult as each packet includes a
"Message Authentication Code" (MAC) that is computed from a shared secret. (
https://www.ietf.org/rfc/rfc4253.txt)

Leam


On Mon, Oct 19, 2015 at 1:51 PM, Jim Kinney <jkinney at jimkinney.us> wrote:

> It's about PIDs and parents. Each login (console or remote) has a parent
> PID that the kernel uses to track all child processes. From connection A
> you request a find job and from connection B you start a tar process. The
> kernel internally sees the login PID as the owner of all of those
> processes. That's why zombies get reassigned to PID 1. Something failed
> spectacularly and the child didn't die when the parent died. Now there's no
> way to control the zombie so it get's assigned to PID1 and waits for a
> reboot.
>
> On Mon, 2015-10-19 at 13:42 -0400, leam hall wrote:
>
> Okay, my brain is being stretched. Could use some expertise. I think the
> question is on sessions, but it got me thinking about login sessions. If a
> user ssh's in from Machine X to Machine A, and then opens another terminal
> window and does the same thing, how does the OS keep the sessions separate?
>
> Leam
>
> --
Mind on a Mission <http://leamhall.blogspot.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20151019/a2222370/attachment.html>