4 ms·

Appreciate the seeing the security audit, but I don't think I'd use this on the open internet. As far as I can tell, this does not drop privileges or separate t

Appreciate the seeing the security audit, but I don't think I'd use this on the open internet. As far as I can tell, this does not drop privileges or separate the process so the bit listening on the network is also the bit running as root. A security audit is nice, but it doesn't provide ongoing protection.

old-gregg 9y ago
hackcasual: teleport starts its own unprivileged copy for scp requests. for other exec requests, including interactive shell, it launches those processes directly, dropping privileges as well. [1] > the bit listening on the network is also the bit running as root. well, being root is a requirement to listen on privileged <1024 ports, in that sense teleport is no different from sshd or nginx. once the request is received and authenticated, it launches another process with the privileges of the authenticated user. [1] https://github.com/gravitational/teleport/blob/master/lib/srv/exec.go#L242 https://github.com/gravitational/teleport/blob/master/lib/sr... In fact, this is precisely the reason we paid for the independent audit, to proactively answer questions like this.
- tetrep 9y ago
  Can't you drop privileges immediately after getting the privileged socket? Why do you need to hold on to them?
  - old-gregg 9y ago
    What do you mean "hold on to them"? Teleport needs root privileges to create sessions like `ssh root@host`, like any SSH server would. But DROPS privileges to start the session, i.e. when they no longer needed. I am assuming you and hackcasual aren't familiar with Golang, since you aren't seeing familiar fork()/setuid()? I'll try to explain: "dropping privileges" term comes from the old tradition of forking a child process from a privileged parent. Teleport, instead of calling fork() directly as you'd probably expect C code to work, uses Golang's syscall.StartProcess(), which does the entire fork-and-drop privileges logic, and the new privileges (user-specific ones) are passed as shown in the line of code above. User SSH sessions are sandboxed in unprivileged processes just like you'd expect.
    - devdoomari 9y ago
      I think the parent comment is about running worker-threads in 'nobody' user account. a lot of proper-distro-packaged apps (e.g. nginx on centos yum/ubuntu apt) spawn 'nobody' processes

old-gregg 9y ago

hackcasual: teleport starts its own unprivileged copy for scp requests. for other exec requests, including interactive shell, it launches those processes directly, dropping privileges as well. [1] > the bit listening on the network is also the bit running as root. well, being root is a requirement to listen on privileged <1024 ports, in that sense teleport is no different from sshd or nginx. once the request is received and authenticated, it launches another process with the privileges of the authenticated user. [1] https://github.com/gravitational/teleport/blob/master/lib/srv/exec.go#L242 https://github.com/gravitational/teleport/blob/master/lib/sr... In fact, this is precisely the reason we paid for the independent audit, to proactively answer questions like this.

tetrep 9y ago
Can't you drop privileges immediately after getting the privileged socket? Why do you need to hold on to them?
- old-gregg 9y ago
  What do you mean "hold on to them"? Teleport needs root privileges to create sessions like `ssh root@host`, like any SSH server would. But DROPS privileges to start the session, i.e. when they no longer needed. I am assuming you and hackcasual aren't familiar with Golang, since you aren't seeing familiar fork()/setuid()? I'll try to explain: "dropping privileges" term comes from the old tradition of forking a child process from a privileged parent. Teleport, instead of calling fork() directly as you'd probably expect C code to work, uses Golang's syscall.StartProcess(), which does the entire fork-and-drop privileges logic, and the new privileges (user-specific ones) are passed as shown in the line of code above. User SSH sessions are sandboxed in unprivileged processes just like you'd expect.
  - devdoomari 9y ago
    I think the parent comment is about running worker-threads in 'nobody' user account. a lot of proper-distro-packaged apps (e.g. nginx on centos yum/ubuntu apt) spawn 'nobody' processes