Ever wanted to use SSH to connect to an embedded Linux system over the serial port instead of suffering through some janky login program that supports very limited terminal features?

Well, I did, and the tooling didn't exist, so I made it.

It also supports ppp automatically.

cc @AMS @chaos

https://github.com/ryancdotorg/ugetty

GitHub - ryancdotorg/ugetty: A modern, lightweight, multi-protocol getty.

A modern, lightweight, multi-protocol getty. Contribute to ryancdotorg/ugetty development by creating an account on GitHub.

GitHub
@ryanc @AMS @chaos huhhhhhhh. neat. if we did things that way we could use scp instead of our current workflow, which uses xmodem.
@ryanc @AMS @chaos (we don't trust our own LAN, so we have a workflow for bringing up new machines using the serial port)
@ireneista
That is an interesting trust boundary. I’m curious what makes you draw the line that close
@ryanc @AMS @chaos
@c0dec0dec0de @ryanc @AMS @chaos well, because it's been clear to us for a long time that there's a lot of stuff on any home network that absolutely does not deserve trust. we feel like recent botnet-router stuff has validated this approach, but at the time we started doing this that was a purely theoretical concern... we just felt it was clearly an important one.
@ireneista @c0dec0dec0de @ryanc @AMS @chaos I like this. Even though I run my own NAT router / DNS / DHCP / et cetera, I don’t trust consumer devices on the same network. Corporations these days seem anti-security, which is to say they’re the ones actively doing evil things that we need to guard against.
@AnachronistJohn
I wouldn’t trust the software on my smart TV, but I don’t see an alternative to trusting my router and switches to route packets properly. I can see only trusting point-to-point comms between devices to an extent, but at done point I feel like I’d be chasing an elusive root of trust. Do those devices need to be running chipsets that I understand? If so, I’m fucked. I’m not Bunny Huang.
Understand that I’m not trying to argue against whatever your threat model is, just say that I’ve considered not trusting the DHCP server and the string parameters it passes in an ostensibly closed system and the engineering team decided that if you got that kind of toehold on the network, you could take the machine because there wasn’t any point in putting further effort into securing against that threat.
@ireneista @chaos @AMS @ryanc
@AnachronistJohn @ireneista @chaos @AMS @ryanc fuck, now I want to rearchitect this stupid boot setup we had with proper service units and maybe figure how to borrow the layering from container models instead of using a bare dm COW overlay and splatting a series of tarballs into it. Not that my employer wants this to be better or that I even work on that generation of the system or that that system image is anything but frozen for all time…
@c0dec0dec0de @AnachronistJohn @chaos @AMS @ryanc well, like, trusting them to route properly is a different thing from trusting them not to infect our other stuff
@c0dec0dec0de @AnachronistJohn @chaos @AMS @ryanc happily our personal infrastructure is a lot smaller than most corporate infrastructure. it's possible we're fooling ourselves that we think we can defend it; we won't know until too late. we do tend to think that there being less to defend is helpful.
@c0dec0dec0de @AnachronistJohn @chaos @AMS @ryanc also the toehold reasoning sounds like it might be assuming human attention from the attacker, and we don't think that's a valid assumption if so
@ireneista physically separated network with very limited outside communication, most nodes booted from write-protected flash and got further instruction/software load from a central server. If you owned the server, there wasn’t a lot we could do on the nodes that we were comfortable doing. I mean, we could have converted it into an open problem of key management (probably the correct thing to do), but the organization was really not prepared to do that.
@AnachronistJohn @chaos @AMS @ryanc
@ireneista so are you doing your initial software load completely offline with a point-to-point connection to a system you trust rather than committing the install media to storage?
@AnachronistJohn @chaos @AMS @ryanc
@c0dec0dec0de @AnachronistJohn @chaos @AMS @ryanc mm. that's the goal, we're only partway there though.

@c0dec0dec0de @AnachronistJohn @chaos @AMS @ryanc we have some devices that come with no firmware (common on SBCs); to bring those up without install media would require using a JTAG connection or something. we're unsure that that's worth it.

for devices that come with firmware, there are potential flows using net-boot features, but we don't have any productionized quite yet.

@c0dec0dec0de @AnachronistJohn @chaos @AMS @ryanc right now, it's more that we use the direct connection to make sure we've got the real host key, and that sort of thing
@ireneista despite owning a few SBCs and previously owning the odd uboot device, I tend to forget that one can’t just PXE over the network for everything (if desired). Although that’s not exactly the most secure system from my recollection of the state of things.
@AnachronistJohn @chaos @AMS @ryanc

@c0dec0dec0de @ireneista @chaos @AMS @ryanc I once stood up a DHCP server and PXE boot server on a network that already had them to show that it wasn’t just theoretical that someone could do something nefarious.

Some people, even those who really should know better, can’t think like that. Point out that it might not be an evil employee but might just be a compromised laptop, and suddenly it makes much more sense to them.

It’s amazing how often we have to show people examples because their imagination can’t easily get there from here.

@AnachronistJohn @chaos @c0dec0dec0de @AMS @ryanc yeah one of the best pieces of advice we ever heard about communicating with lawyers as a technical person is, come up with a concrete example

(applicable elsewhere too, of course)