Teleport (YC S15) | Backend and Fullstack Engineers | US, Toronto, London, Remote OK | https://goteleport.com
Do you enjoy building security and deployment tools for other engineers? Join us to hack on https://github.com/gravitational/teleport. Most of our code is Go, we have very little technical debt, our codebase is clean and small.
If you are a backend or fullstack engineer, we expect you to be comfortable with the following:
* Go for backend and Go+TypeScript for fullstack engineers.
* Linux, networking, and security.
* Scalability and/or security experience for systems software is welcome.
We're looking for senior engineers to join the Teleport team. Teleport is a company started by engineers to build products for engineers. We are a stable and growing company.
We offer:
* Competitive salary and equity.
* 401k with company match.
* Excellent health insurance.
* You will join a 30 minute intro call and we will walk you through compensation, the interview process, and requirements.
* You join a private Slack channel and submit a coding challenge in Go (backend) or Go+TypeScript (fullstack) depending on the position using Github.
Teleport (YC S15) | Backend and Fullstack Engineers | US, Toronto, London, Remote OK | https://goteleport.com
Do you enjoy building security and deployment tools for other engineers? Join us to hack on https://github.com/gravitational/teleport. Most of our code is Go, we have very little technical debt, our codebase is clean and small.
If you are a backend or fullstack engineer, we expect you to be comfortable with the following:
* Go for backend and Go+TypeScript for fullstack engineers.
* Linux, networking, and security.
* Scalability and/or security experience for systems software is welcome.
We're looking for senior engineers to join the Teleport team. Teleport is a company started by engineers to build products for engineers. We are a stable and growing company.
We offer:
* Competitive salary and equity.
* 401k with company match.
* Excellent health insurance.
* You will join a 30 minute intro call and we will walk you through compensation, the interview process, and requirements.
* You join a private Slack channel and submit a coding challenge in Go (backend) or Go+TypeScript (fullstack) depending on the position using Github.
That's a good question and valid skepticism. The UI serves two purposes.
The first is to manage your cluster. For example, you may want to change a users role (to change what servers they can access) or play back a session recording to see what a user did within a session. You can do all of these things from the CLI, but sometimes you don't want to remember the exact command and flags, that's where the UI comes in.
The second is to have access to servers from an environment that either does not have robust SSH support, doesn't allow you to install software, or maybe an environment (temporary) into which you don't want to install software. For example, when the UI was first written Windows did not have great support for SSH certificates, but the UI would allow Windows users to access Teleport clusters.
Lastly, the UI is completely optional, in addition even the CLI tool is (almost) optional. Once you've fetched your certificate, you can use your OpenSSH client as normal. In-fact a lot of people use Teleport this way.
Can you get your certificate without using a browser? The description in the "how it works" sections here [1] describes it launching a browser for that step.
If it has to use a browser, can it be a non-GUI browser like Lynx or Links?
I have followed eBPF development from afar, so I don't exactly where it's at. I have a ... semantics question: do people really refer to eBPF as BPF ?
This is probably bothering me more than it should, but why do overload terms when a more correct solution is available from the start ? The BPF virtual machine is not exactly new. For example, tcpdump supports BPF. Not eBPF, though.
If we start referring to eBPF as BPF, then pretty soon other OSes using BPF will be referred as having "incomplete BPF implementations" because Linux has eBPF and we incorrectly refer to it as BPF.
Understandable confusion, I've seen it referred to both ways. We decided to go with BPF for this blog post since that appears to be the official abbreviation.
From "BPF Performance Tools" by Brendan Gregg:
"Extended BPF is often abbreviated as eBPF, but the official abbreviation is still BPF, without the "e," so throughout this book I use BPF to refer to extended BPF. The kernel contains only one execution engine, BPF (extended BPF), which runs both extended BPF and "classic" BPF programs."
Just a quick note that 19.04 Ubuntu reached EOL on Jan 23rd, 2020. Ubuntu has several releases that support 4.18+ kernels [0]. I recommend using 19.10, but you can also use a more recent HWE kernel for the 18.04 LTS [1].
What's the threat model being addressed here? If someone is trying to act maliciously there must be a thousand ways around calling exec (for example just mapping a program and jumping to its main function accomplishes the same thing).
We're trying to raise structured behavioral information about what is happening in a session to the cluster administrator.
That means we don't just provide information about what's executing, but also what files are being opened and TCP connections being established. Other avenues of expansion you may see this feature venture into: how were files changed, support for other protocols, support for other events (bind, listen, accept).
However we are not claiming this approach is not subvertable, but we do want to raise the bar for attackers and make it easier for cluster administrators to understand what is happening within their system.
Doesn't that just end up calling open() and mmap()? Might not have access to the args passed through at that point, but that's going to leave a trail and of course anything interesting the mapped program does will end up going through syscalls(opening other "files").
Though it should be noted that's not quite the same thing as execve. Execve does a lot of things in addition to running the main function (privilege transitions like setuid being just one example).
Of course; in addition to kernel setup this will also skip over initializers in the binary and other things that the C runtime does before main. Needless to say, this is mostly only useful as a fun side effect of PIE executables.
Mr Jones, this and all of your articles are just delightful. Can you share any early feedback from the field or end-user testing? Have folks been happy that this ticks compliance checkboxes even if the current solution may be subverted by root users?
So far we have gotten positive feedback. While this feature does not protect against root doing something malicious, it does allow admins to capture what root was doing up until they did something malicious and link that information to an identity (if using SSO).
Along with this feature we rolled out a Workflow API [1] that can be used to request role elevation. Once you add in session termination (which we are aiming for in the next release), you will have a powerful set of features that will allow you to start users out with limited access to your cluster with the ability to request more privileges and potentially automatically termination your session (and user) if you're found to be doing some malicious.
When is a capability like this turned on? Is teleport running all of the time (seems like a huge log of data, no?), or only when anomalous behavior is detected? or... something else?
I ran an eBPF program called opensnoop [1] to capture what files were opened during login to a system and then re-launching bash. Looks like both are read during initial login but only .bashrc for non-login shells. Output is below.
Be careful that some of those files explicitly include others. For example my (default) ~/.profile includes ~/.bashrc, my ~/.bash_profile includes ~/.profile, /etc/profile includes /etc/bash.bashrc...
So your capture here doesn't show only the files that bash itself decided to load. You also won't see the fallback files (e.g. bash will open .profile if .bash_profile doesn't exist).
Maybe I did not provide the best example, but the point I was driving at is that the restrictions here are at the application level and not at the system level.
If you take the approach you are taking, similar to ForceCommand, you have to make sure none of the commands in your PATH allow code execution. For example git, vim, less, awk, and find, all of which I use on a daily basis, can all be used to re-launch a restriction free bash.
Once you remove all the commands you have to, how much of a shell do you have left?
> but point I was driving at is the restrictions here at the application level and not at the system level.
Your point is well-taken!
I'm obviously not privy the the conversations you've had with potential customers, so I'm not entirely sure what they're asking for. But (IMO) the way to think of a restricted shell is to think of it as a shell that can't do anything, except for a small list of narrowly defined tasks. Thinking of it as a normal full shell, with "unsafe" things disabled, that's a losing game, as you note.
We've made improvements in resource utilization for Teleport 2.0 and hunting down any further resource utilization issues is definitely one of my focus areas for Teleport 2.x.
If you run into issues like this again please reach out and send us your teleport.yaml, we want to run these issues down and resolve them.
Do you enjoy building security and deployment tools for other engineers? Join us to hack on https://github.com/gravitational/teleport. Most of our code is Go, we have very little technical debt, our codebase is clean and small.
If you are a backend or fullstack engineer, we expect you to be comfortable with the following:
We're looking for senior engineers to join the Teleport team. Teleport is a company started by engineers to build products for engineers. We are a stable and growing company.We offer:
Apply: https://jobs.lever.co/teleportWhat to expect once you apply: