Per subject - why does piaware/faup1090 run as root (and, in fact, refuse to run as non-root if you try that?)
There doesn’t seem to be any need for root privileges, and they’re both non-trivial enough that I’m not particularly happy about running them as root.
5 mins of hacking on piaware produced a version that’s running as non-root and seems to be happily uploading messages.
(basically: disable the root user check, move the config file into /etc, put the pidfile in a directory writable by a non-root user, discard stderr from netstat output)
faup1090 shouldn’t need root ever, I think.
dump1090 needs USB access but otherwise nothing special - that can be handled with udev rules.
Could the standard packages be changed to support this?
PiAware runs as root because it’s just ever so much easier to do it that way. It is true that there isn’t like some device permissions or system call that it has to be able to run that requires root, and another user has figured out how to run it as an unprivileged user. There are however a preponderance of reasons that have added up to our doing it the way we do it:
creating and running as an unprivileged user adds considerable complexity to creating a Debian package
It adds wrinkles to the start-stop script in /etc/init.d
if it runs as a different user then the piaware-config command has to run as root or you have to invent a way for the user to have permissions to edit a file they don’t own
some other stuff
Finally the remote update capability is something that the vast majority of users are going to be ecstatic about, and since it’s opt in for people who install from the Debian package or from source code, we’re going to keep going the way we’ve been going for the time being.
Karl
PS - If we ran on your desktop then we wouldn’t approach it this way, but we wouldn’t as much need to. Likewise if we were running on some big Internet server.
Isn’t it just one adduser command in the postinst script?
[li] It adds wrinkles to the start-stop script in /etc/init.d
[/li]–chuid and --user in start/stop respectively worked for me.
[li] if it runs as a different user then the piaware-config command has to run as root or you have to invent a way for the user to have permissions to edit a file they don’t own
[/li]
I don’t mind piaware-config having to run as root, it’s the daemon I am more concerned with.
[li] a bunch of other stuff
[/li]
I’m sure there are a bunch of other solutions there
Finally the remote update capability is something that the vast majority of users are going to be ecstatic about, and since it’s opt in for people who install from the Debian package or from source code, we’re going to keep going the way we’ve been going for the time being.
Surely if remote update is not enabled then you do not need root?
I would still argue that you really need to break the remote monitoring and upgrade bits out from the data feeder bits - they have quite different access requirements.
PS - If we ran on your desktop then we wouldn’t approach it this way, but we wouldn’t as much need to. Likewise if we were running on some big Internet server.
This is the mentality that leads to things like network attacks that trampoline via printers unfortunately (because who cares about printer security, it’s not a desktop!)
If you could put the Debian packaging metadata/scripts on GitHub then I would be happy to send you pull requests or produce my own packages that avoid running as root unnecessarily.
On a related note it is at best risky to run dump1090 as root, given that it’s a big bit of mostly unreviewed C that already has a history of memory management bugs…
Yep, and if one has given --net parameter to dump1090 and opened the firewall for e.g. 8080 (or whatever is the local http port is), how sure one can be that it is impossible to utilise that for attacking the system?
Over the years, I have found that it pays off to always be a little paranoid about security.
A quick reply for right now. Your point about dump1090 is compelling. We have updated our fork and made pull requests upstream to improve its security for holes we found in it in URL handling, and really, that it is web facing it shouldn’t run as root, and we’ll fix that.
Maybe there can be an update wedge that’s set user ID to handle updates that people who don’t want to allow that can take even greater comfort by removing it or removing its privileges.
One minor point. The population that is running Piaware runs the gamut those who can code drivers from scratch to those who have some trouble finding the ‘any’ key. FA is trying to put out a an application which is as easy as possible to maintain and need to target the lowest common denominator. One uses it by simply downloading their image, burn it to a card, plug in the RPi and go. If you want to tweak yours to run unprivileged, that is fine. I choose not to run their and build from a basic OS image, as is my choice.
I would argue that, because many users will just install the package or OS image and not tweak it, the default package should have sensible secure settings.
Running as root by default seems a little reckless; there’s no technical reason to do it here.
I can see the argument for auto-updating of installs that otherwise would never see an update, that’s fine, but let’s separate that bit out so that the whole feeder doesn’t need root.
I agree. Making it as ‘idiotproof’ as possible does not mean making it insecure. A second set of eyes or slightly different perspective is a great development tool.
Well, yeah, and it’s all on github and we haven’t tried to hide anything and there are a lot of comments in the code explaining what we’re doing and all the Internet traffic between the Pi and FlightAware is encrypted, and by TLS and explicitly refusing SSL v2 and v3 long before the recent vulnerabilities came out. I guess I’m trying to say we haven’t ignored security by a long shot.
I’ve already (if just) agreed to move dump1090 out of running as root. Originally we didn’t even consider dump1090 to be our remit and for “classic” piaware users it isn’t it, and whatever we do has to recognize and not step on installs we didn’t do, and developing and testing and supporting all that stuff adds up. I’ll also bet you that pretty much everyone who was running dump1090 from instructions they found on the net was and is running it as root. Not a justification or anything; again pointing also to costs, and other resource limits like complexity, peoples’ time and developer time.
Not trying to point fingers about security at all! You’re already doing a far better job than your competitors-who-shall-remain-nameless where there’s no source code available for their feeder at all
If you need a hand with the heavy lifting, then as I said I’m happy to help - I just need the current package infrastructure so I’m not duplicating it (at least, I couldn’t find the packaging bits on github at the moment - perhaps I’m looking in the wrong place?)
Yeah it’s in a private repo right now. Uh, there’s some stuff there that we know is gross but if you promise not to hoot too much I’ll migrate it to github.
Yeah - I hated this SO much and having a spare subnet available on the office firewall - the Pi lives on it’s own subnet and I did a little port mapping just to obfusticate things a little.
Which means internally I go to the external facing public IP and port to see what is going on…
–
I run into this sort of poor practice more and more these days. We were supporting a banking app install at a client last month and it wouldn’t work. The bank had us blow so many holes in the firewall and in internal security to get the package to work (a CC payment system no less) that I advised my client to get a liability waiver from the bank before they even used it.
–
Don’t get me wrong - I’m happy to contribute to the FlightAware community - but if I had not had a spare subnet available on the firewall - we would not be here.
I’m sure there are some things that are gross in the builder and we will appreciate feedback on how to improve it and make it more standard. We take (pull) requests, too.
The biggest thing on my mind is have the install set up a user and have the init.d script run dump1090 as that user. From there, how to simplify the build process and use more standard methods as available and then finally, whatever else you see.
I wonder whether it makes more sense to directly include the debian controlfiles within your fork of dump1090, rather than having the separate steps to repackage & merge the packaging parts with the dump1090 code?
edit: I went ahead and did this locally, it seems to work much more smoothly - the package build process is down to “git clone, then dpkg-buildpackage” with no pre-packaging build steps needed, the whole build is driven by dpkg-buildpackage. Also means you don’t affect your local install when you do a package build, which was the main gotcha for me when trying your build infrastructure. It’ll happily build on x86 now too.
Should have a pull request for you later today. Then on to the run-as-user bit, which should be very straightforward.
Eh, there are a lot of files in the packager and I would prefer not to complicate the source tree with Debian package making plus it seems inevitable that we’re going to eventually need to support other packagers. I like the idea of keeping the application, whether it be dump1090 or piaware or whatever, separate such that someone working from sources can do makes and make installs and never need to worry about or dig into the complexity of packaging unless they really really want to.
I’d prefer to head in the direction of more automated packager where you could just say here’s a list of files, here’s some metadata, here’s the change log, go. The piaware builder is real close to the dump1090 builder, for instance, so what we have, if clumsy, already points in that direction.
It’s noninvasive, the changes consist of updating the Makefile to understand $(DESTDIR) (which is desirable anyway), then all the other changes consist of adding files under debian/
