Well, the passwords (hashes) are already publically known right?
With no buttons at all, you probably want something like
sudo snap install hibp
sudo hibp.initialise
//Wait until the 40GB download is done
sudo snap start hibp.server
No reason to authenticate a public database.
Initialise will be able to write to $SNAP_DATA because you gave it root. It won’t need home though.
I agree. For me personally, I try to have 2 silos. My personal computers, phones etc. And the public services I provide to people on servers via sysadmin. I take a very different approach to each.
As you have prob detected, a significant part of my sysadmin work has been on BSDs, and to be honest they do feel fundamentally different to all Linux flavours. Everything is much more manual and auditable and designed for the server.
I do feel slightly uncomfortable administering ubuntu LTS server, which is essentially “a desktop OS without a window manager” on a server. This conversation has probably enhanced that feeling.
yes, absolutely true. These are not secrets.
But I do not want someone to trigger a 40GB download from a webinterface, let alone an unauthenticated one?
What is wrong with just recommending users make and launch a service manually? Just don’t use that aspect of snap?
Well, the daemon part is mostly about it just being a conveniently managed service. You’re right you could trigger it manually, that’s fine too.
Then it’d just be
sudo snap install hibp
sudo hibp.initialise
//Wait until the 40GB download is done
sudo hibp.server
// control-c to exit
I felt it might, but honestly is the best policy; and I feel you’d have similar experiences in other distributions/communities were they honest.
BSD has recognition for security for a reason. We’re talking in a Linux community that actively tells the rest of the Linux community we don’t like how things are done, so imagine what the conversation would be like elsewhere.
yes, “try it out… then control-C and make a service”
Hopefully that let’s you get somewhere usable (assuming you’re still happy to try), and assuming it works, hopefully the end result will be something that uploads without any reviews needed and benefits from the sandboxing ( even if you end up turning the autoupdates off 
)
I’d imagine at this point, the threads gotten too long for a proper review to be possible (it’s about 20 times longer than most), and unfortunately, as far as classic goes, I feel you neither need (and probably at this point, want) it. Feel free to keep asking for help/opinions (I might disagree with some, but ultimately that’s how people learn, thanks for being respectful where we have); but I’d encourage for the benefit of the review team that the original post is updated to discard the request whilst hopefully the ammended version works for you.
In summary, it seems to be come down to, ensure you’ve network and network-bind, and ignore the question of “where can users place files”, don’t give them a choice and put them in $SNAP_DATA for them. Force them to use sudo should they want to open ports 443 (as Ogra says, that’s a Kernel policy not a snap one). But the overall user experience doesn’t have to be awful, done properly, it really would be approximately the three commands above (ignoring any extras we’ve not discussed, there’s a few apps: in your build file, which might need more ideas),
You can choose to ignore it being a daemon, but, being a daemon wouldn’t be any different from a security POV ( when strict ), it’s just the init system launching it automatically. The sandboxing still kicks in.
And hopefully the bit about the review system being in depth with automated help and manual inspection and identity verification gives you some assurances.
is it still worth requesting this on that other thread?
Given I am going to be writing some more detailed instructions on how to make a service etc, it would help not to have to say “or the dot version if you installed via snap” every second bullet point?
I’d request this in a new thread.
Aliases aren’t controversial, you’ll be waiting a week, but they’re almost always granted except where obviously malicious or misleading, and will be much easier to action separately.
Yeah I meant separately. Thanks
No worries.
Just to be clear with the aliasing, the mechanism is the same as interface overrides, canonical sign an assertion saying the store team approves this.
Explicitly then, they’re only automatic when installed from the store with the rest of the signature, when installing with --dangerous, you won’t have that, and would need to use sudo snap alias manually, but your users wouldn’t. (And yourself, assuming you have separate build and deploy machines).
If curious, you can try snap download $foobar and you’ll also get an .ack file which is just a GPG signed entry which should be pretty readable as is.
I definitely don’t want classic, so the request is definitely withdrawn .
During this discussion I have uninstalled all classic snaps on all servers I have control over.
In fact, I feel the same about --strict snaps for servers as well. I am not using any, and will probably avoid them in future. So I am kind of in two minds about whether to recommend to users to install my software as a --strict snap, given it is intended for servers.
It’s a shame, the jailed build aspect is great. And I feel that for servers, if snap had a mode where it did “a lot less”, that would be much better: --sysadmin as discussed above. Don’t run anything, don’t make daemons, don’t autoupgrade etc ,but equally don’t get in the way when the sysadmin speaks.
I don’t agree or maybe understand this…? That’s not what we discussed as far as I can see.
I can’t “put the files in $SNAP_DATA”, as you seemed to confirm above, without running a “root inside the snap” webapp daemon, and triggering it from over http, which is really inappropriate…
If not done super carefully, it’s effectively a DNS attack. That download cripples your network connection. That’s the whole point!
Unfortunately I think it’s pretty unlikely. There’s --devmode, but it’s devmode because whilst it disables the sandboxing in forms of apparmor, cgroups, eBPF, etc, it doesn’t disable e.g., mount namespacing, which is intrinsically inseparable from the container-ness of snap (and Linux in general).
I.E, whilst --devmode basically implicitly goes “I have no issues with you accessing /var/www”, you might find that, should you try, the snap still doesn’t see /var/www, this isn’t because the sandbox is blocking it directly, but because the mount namespace removes references to it because you need to ensure that all the system libs are ABI compatible, and that mechanism can’t just be removed without breaking everything. (by comparison, --classic doesn’t have this mount namespace and sees everything).
Other platforms will have more control over how precise that happens, so, in parts it is a snap problem moreso than a Linux problem; but the mount namespace itself basically always has to be used to some degree in Docker or Flatpak or whatever, the question is, how much?
Imagine a script in pseudocode like so:
#!/bin/fake-bash
if user == root:
wget https://hibp.database $SNAP_DATA/hibp.database
else:
print "Please use sudo and run this command again"
If the user runs it without root, it’ll give our nice comment to try again. If you didn’t put a check in, it’d error if they weren’t sudo, because they wouldn’t have permission to. You’d rather a check to handle it more gracefully, but hopefully that’s accomodatable.
You’d link that script as an app in your snapcraft.yaml and instruct people to run it prior to running the server (daemon or otherwise).
Flatpak is hopelessly inappropriate for this kind of thing.
Docker is probably the most natural fit, as far as I can tell right now.
In some environments, it’s a common policy to deny Docker because it has its own security issues. Specifically for CERN for example, it’s not allowed at all on the HPC nodes for security.
As I say, computers in general unfortunately, each persons tolerance to risk will be different.
I don’t really understand your suggestion, and I am not sure you are understanding the intent of the set of cli utilties.
They are not optional. And they do not want to be replaced by a “set of bash scripts” which call the http server which then calls the cli utilities.
The only way I currently can see, is to make an http service separately outside of the snap. I would probably make a separate user, hibp or whatever, who will have its own home dir, and su to that user, start the server and drop to background.
The details are to worked out here, and to be docs written, and I fully expect to fall foul of the “confinement rules” several times along the way, and have to work around them. I don’t know if this will be possible, or indeed if the effort required to do so, will make snap an appropriate distribution mechanism.
But that’s where we are as far as I can see…
I can try build your snap another day and see if I can give some practical tips, since this is moving more on implementation specifics, that’s probably needed now to bridge my knowledge gap on the actual specifics, but at a high level, there’s a path available and it’s working out what works best for security (and user experience)
Yes, I know. HPC not target. However, docker is super widely deployed in webapp and microservices space. People know how to work with it.
I feel perhaps this is where this (actually very small) app fits.
I agree, Docker does also seem appropriate, more just a warning that Docker has its own issues if you look them up, to the point that where you’re averse to snap from the discussion, people will be averse to Docker for similar reasons, both in its design (it basically gives root access to anyone who can communicate with the socket, at least historically; there’s rootless modes available now but then these come with compatibility compromises), and its ecosystem (Dockerhub is a playground of abandoned packages with outdated dependencies with known vulnerabilities). That’s not me saying it’s inappropriate for you, but hopefully gives some balance to how snapd handles things vs the other available choices.