• 2 Posts
  • 39 Comments
Joined 3 years ago
cake
Cake day: August 10th, 2023

help-circle

  • I don’t have/use TPM, but I do have encrypted swap and hibernation on a fully encrypted drive.

    The trick is to put the kernels in the root partition, which is encrypted by LUKS. Then, you can also put a swapfile in that same partition.

    The only unencrypted part of my system is /boot/etfi, which is the EFI partition that holds nothing but the grub binary. Grub configs and kernels are in /boot, which is on the root partition, and encrypted in LUKS.

    Grub automatically scans hard drives, before prompting with a password to decrypt the root and everything on it. Because grub is doing the decryption, rather than the kernels, the kernels and swapfile are decrypted all at once.






  • EDIT no wait, this post is about secure, not hosting/tunneling in general. This comment is off topic ig.

    I would like to avoid paying for a VPS

    Oracle cloud free tier, but it does have a history of randomly killing the VPS’s created.

    Public ipv4 addresses are scarce, and becoming more expensive now. You are probably going to have to shell out some cash if you don’t already get one as part of your internet plan.




  • Tailscale works great, but their free tier is limited to a total of 8 users, which is enough for a tiny minecraft server, but doesn’t seem to be enough for your usecase.

    For 10-15+ users, you probably want to self host a VPN on your own VPS. Like, you can self host headscale, which is tailscale but self hosted. : https://github.com/juanfont/headscale [1]

    I wouldn’t port forward game servers, because they often lack authentication (login and stuff), and then they also have security issues due to not receiving updates. If your game server isn’t truly public, then it’s easier to just have people use the tailscale client to connect to your VPN.

    [1] Although I would recommend headscale to OP for it’s simplicity, it is very barebones, and software like netbird or netmaker is more close to a truly self hosted tailscale, with things like more advanced accounts, OIDC integration, authorization, and so on. But they are more annoying to host and set up.



  • A common distribution method involves multi-party signing, that is, multiple developers use keys to sign off on reviewed changes.

    Multiple developers review the changes, before signing the git commit after review. Then they build the package, either locally or on CI servers, but again, multiple parties/servers sign and review, doing a reproducible build to verify across machines.

    In an ideal architecture, there is never a single point of failure. You would have to compromise the computers of multiple devs, or multiple build servers that are building signed reproducible builds, in order to do it.

    Although in theory, you could compromise all of them. But it’s extremely difficult.


  • Anyway I was gonna write a rant about it but I’m too tired. But basically the docker ecosystem is kinda fucked in this regard, and trades security in many aspects for convenience of development and distribution. This is one of the most notable examples of this.

    It’s popular because it’s convinient and easy to use in many ways. If these pitfalls are a dealbreaker for you, then there is no trivial way to add the security requirements you are asking for.

    You can pay for signed images from someone else, which is a little better, but there are still disadvantages.






  • Yes, although there have been a few CVE’s related to escalating privileges or breaking out of the sandbox. You’re going to want to keep those updating and keep on top of those.

    There is one concern, in that the nix store (/nix/store) is world readable. It is not world writable, which is good, but there is a problem in that secrets can potentially be copied into the nix store. If you copy a file containing environment variables or the like into the nix store, it could theoretically be found it. This one is on the users of nix to be careful of.

    With Nix flakes, the entire git repo that the flake originates from is copied into the nix store. Meaning if you have a nix flake in something that is supposed to be a private repo, or contains tracked sensitive data (untracked files are not copied into the nix store), then it could be found and inspected by other users.

    My big concern with multi user in this case is not merely the Nix daemon though, but also Linux itself. Linux has been hit with a LOT of privilege escalation and container escape issues over the past few years, and many of them have been zero day’s. Given this, I no longer really have the same level of trust for Linux with regards to multi user isolation, for in cases like these.

    Of course, in academic computing, I would probably just do multi user anyways, for simplicity. If you install tracking and monitoring, then you can attach malicious actions to identities. Because every user is registered and operates within the institution, if they break the terms of use for computing equipment, then you can punish them within the institution, or pursue greater legal action.

    And then, you also would want to enforce 2FA to help minimize stolen accounts. While that can still be phished via fake login pages that ask for 2FA, it handles most of the things. Isolate the server via firewalls, and then it becomes a small enough target that doesn’t have enough value (assuming of course, your research isn’t too valuable and worth targeting), and you mostly don’t have to worry about it.

    Sure, people will root it. But then they’ll send you a nicely worded email explaining how they rooted it and how to fix it. Which is what my friend did at my school, on our shared ssh server. Just keep it updated to handle the low hanging fruit.

    However, if you are going to give it to untrusted users with unknown or temporary (not within the institution) identities, then things change, and you have to take it a lot more seriously. I no longer have confidence in just Linux’s user based isolation.

    The first line solution I would go to, is to put users in containers and mount the nix store (and nix daemon) in and out. Something like a docker/podman container or Incus container. Of course, container escapes are still possible. If you are even more concerned about those, then you would want virtual machines. It is still possible to share the nix store between virtual machines, but it is more complicated.

    In addition to that, virtual machines have a performance tradeoff (usually 95% or more of the host’s performance though), but there might be issues with sharing GPU compute resources among virtual machines, depending on the hardware you are using. Enterprise GPU’s usually support it though.



  • the physical display output is claimed by something else totally separate.

    Yes, and the above solution I laid out is a way to get around that, that potentially dodges the complexity of configuring a truly headless session. It’s possible to run two KDE sessions at once, next to eachother, and then simply put one on the main display, with the second being “headless”, and not shown.

    I started fiddling with the above setup I described, actually installing and testing sunshine. Unfortunately I hit some hiccups. I got sunshine to run, but with no input, and then then it attached to the wrong KDE, even though it was streaming the correct one initially. Now I’m running the same KDE session as a different user (since I was on the same user before), but having pairing issues, but I suspect these are because moonlight is seeing the wrong SSL cert, since the sunshine as a new user generated a new cert.