Other than encrypting my local workstations, you can also use it on VMs from linode/digitalocean/aws/gcp/etc. If you store all your sensitive data beneath /home for example, you can boot the instance, use OOB console to access it, decrypt and mount /home, then SSH and it's business as usual. This gives you (some) protection against a malicious actor at your provider snooping your volumes.
edit: typo
And the cryptsetup tools / kernel has recently added support for Windows Bitlocker encryption as an alternative to LUKS, obviously only really appropriate if you deal with Windows images or need interop with Windows.
> so I decided to encrypt my disks
Where is the data encrypted? Local or remote? If its done remotely, whoever owns the hardware and has root on the host OS has your private key. Even with rented servers, where you are root, the KVM is king.
Combined with AMD-based (SEV) confidential computing and shielded vm you can get close to what on-premises hardware offers.
Nothing can truly replace hardware you own (except maybe fast fully homomorphic encryption eventually) but if you can trust the firmware that Intel/AMD, HP, Dell, or Supermicro ships in a box then the cloud is 99% as good at this point.
FYI, Nitrokey runs Solo FIDO2 implementation [1], which is also used by Signet HC and OnlyKey. So all these FIDO2 keys will work with LUKS2.
And if any maker of keys is reading, please reach out if you're implementing U2F but want to upgrade to the full FIDO2, including the hmac-secret extension.
I am also really looking forward to the YubiKey Bio getting released too.
There have been a number of attempts to solve this problem, but the most complete appear to be Mortar (a project I head) and safeboot.dev
I highly recommend taking a look at either of these projects if you want be able to improve both your convenience through auto unlocking, and security through broadened scope of audit.
My Security Key 2 reports lacking this extension.
This is what the comment said before I updated it, in case it's important context for replies:
I believe that they do implement hmac-secret yes. For what it's worth this is the same feature (for the same reason) you need to enroll FIDO authenticators to unlock a Windows system, so if you use one to do that today, it definitely ought to work with this too.
I intend to spend the next few minutes playing with code to check I'm correct about this, but I might get distracted, so either there will be an edit saying I was right, saying I was wrong, or no edit because I watched Youtube.
During another activity I was talking to somebody about this test, and when I visualised it in my head I realised that even though I was talking about testing my "Security Key 2" I had actually tested a much simpler/cheaper Feitian based U2F authenticator I own because it was in my pocket and I just instinctively use the one I'm carrying for FIDO authentication.
Unsurprisingly this cheaper device doesn't do hmac-secret.
However I have now fetched my actual genuine Yubico Security 2 and re-tested that, and it does have hmac-secret despite Yubico's own site seeming to suggest otherwise.
The chances anybody is reading this for any reason other than to point out I was wrong are small, but just in case this is found by somebody's later Google search here it is.
Here's some example output from Yubico's example app (the secrets here are random and worthless)
New credential created, with the HmacSecret extension. Authenticate with salt: b'21cef9e80517c7527ddaea4229ea36c675c539da7f98ecf3878dfc026caf4a6d'
https://support.yubico.com/hc/en-us/articles/360016649319-Yu...
For example, ssh-agent can sign arbitrary data via its wire protocol. Lots of USB security keys expose their functionality via ssh-agent.
https://tools.ietf.org/html/draft-miller-ssh-agent-04
Does LUKS / cryptsetup provide hooks for deriving a key from a blob of plaintext stored on the disk?
[edit] There’s the UUID — sign it with your ssh-agent and use the hexdigest as a LUKS key. It sounds so simple it must already exist?
Is this after the bootloader, after initramfs but now systemd-cryptsetup is loaded and unlock the first disk?
AFAIK when I do my first disk unlock, at that point does systemd units get loaded including systemd-mounting.
Those mounts can already already mount/unlock encrypted secondary disks, based on the keyfiles stored on the now decrypted disk. So what exactly in this case is the advantage of any of this?
EDIT: Also, is there any discussions over ftpm support? Last I checked TPM2 was ok, but ftpm (which most intel/AMD now using) are a bit flaky in regards to support.
At early boot and when the system manager configuration reloaded, /etc/crypttab is translated systemd-cryptsetup@.service units by systemd-cryptsetup-generator(8).
So this should run during mkinitcpios systemd hook, I think (i.e.during "initramfs times").
EDIT: Also as a service it can also run later one if you e.g. plug in a LUKS encrypted hard drive I think. I haven't tried it out.
it'll need some work from the distros so the whole process is a bit more straightforward.
I went with LUKS1 which grub can unlock.
Now you have the choice to use grub for this or linux itself.
In either case both can be modified to do arbitrary things and corrupt later stages.
To prevent this you use secure boot, and if you want to do it right a custom platform key.
So now you either pack the Linux kernel initramfs etc into a single blob and sign it or do something similar with grub.
In both cases you should have a similar secure system.
But in my experience GRUB's functionalities in this area are not very nice to use and lead to slow boot.
On the other hand directly booting the signed linux blob without a bootloader is fast and smooth, but exposes what is in you initramfs, which normally doesn't matter.
You can configure through systemd-enroll to configure the TPM to only unlock the cryptokey if those measurements are consistent.
If somebody changes your systemd binary in the initramfs; this causes the TPM PCR register to change; and will cause the system to not be able to decrypt the stage-2 rootfs
Clevis, on the other hand, allows to bind the key to a specific machine, preventing the storage itself from being yanked out (where it is still possible) - and you need to trust TPM2, which many do not.
It's all about trade-offs and trust.
[1]: This is older with TPM1.2, but is the 'autoboot' similar to Windows BitLocker, https://ranzbak.nl/tpmluks/ [2]: https://blog.dowhile0.org/2017/10/18/automatic-luks-volumes-... [3]: https://redhat.slides.com/pladd/securing-automated-decryptio...
In the matter, I agree. I'd think unlocking of the filesystem ought to be happening in the boot-loader (either GRUB or ROM resident). Systemd will only be able to do so, if the root fs (typically holding /etc with plenty of stuff worth protecting) is unencrypted. It seems to me this feature was added to systemd just because they can.
Also, the way I understand systemd nowadays is it isn't an init system, it is an API for Linux systems that abstracts low level features in kernel in a consistent way (either using unit files or systemd C interface). It has an init system because it needs control from early boot so it can offer a nice interface for services. Ditto for dbus, mount system, timers, logging, etc. You can use as much or as little as you want, but if you choose not too you need to invent your own way (that was what most distros used to do before systemd).
Also, integration between those subsystems (say, init systemd and cron) was basically writing glue code, while in systemd world they're meant to be integrated (unit files of any type can depend of each other, so you can have a service that depends on a timer, a disk mount and a udev event, for example).
So yeah, you may not like the way that systemd does things, but at least use valid arguments like the fact that things are more opaque (but this is understandable, this is an abstraction layer), or that the declarative approach of systemd makes some things harder (true enough, but you can always fallback to use scripts and you still have all the power of systemd dependency system).
> Also, the way I understand systemd nowadays is it isn't an init system, it is an API for Linux systems that abstracts low level features in kernel in a consistent way (either using unit files or systemd C interface).
Starting as an init system and becoming a general API that abstracts low level kernel features seems like feature creep.
> You can use as much or as little as you want, but if you choose not too you need to invent your own way
Correct. The problem arises when you try using tools not provided by systemd in conjunction with systemd and systemd actively makes that hard. The accepted solution to that problem in the systemd world is to rewrite more tools the way systemd sees fit with the side effect of extinguishing every other approach and dragging linux further away from its BSD/Illumos cousins. This is again a form of feature creep.
Don't get me wrong. I think the tooling available 15 years ago mostly sucked and there was definitely a need for something new. I just don't believe cleaning a mess with a giant monolith is the way to go.
AFAIK systemd and the different components has so many internal dependencies on each other than not much works if you try to pull things apart. You can remove systemd completely, yes, but try to only have systemd as an init system and nothing works!
When my void Linux / alpine Linux systems have internal failures, I can troubleshoot and solve them because the system is composed of minimal abstractions tied together - I can feasibly deduce the root of the problem, and fix it, even if half the OS is missing.
With systemd, it's one big mess. Problems are far more opaque, and the pieces are far more interdependent: it's easier to wipe and start over, thereby treating the os as a black box, than to dig in and find the problem.
I avoid systemd systems wherever I need to do anything with the os itself that isn't extremely ordinary.
Can someone explain why non-systemd systems are claimed to be full of broken shell scripts? I've yet to experience that.
From a developer pov I'm optimistic. systemd seems to be positioning itself as a isolation technology. It gives me a simple and effective way to ship security controls that the user themselves would not be able to do with this granularity (well normally) and it's part of the package / installer (e.g. by default hardened because why bother the user?). And the process for me as dev is really simple too (see below).
It gives me additional options rather than just hope everyone will use firejail and apparmor (even on a debian sid apparmor userspace is too permissive or not properly maintained - firejail is better but rare).
some simple things that can be dumped into a systemd.service file (source https://www.redhat.com/sysadmin/mastering-systemd) to ensure hardening isolation/hardening is always shipped with the package.
RestrictNamespaces=true
RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6 AF_NETLINK
ProtectClock=true
NoNewPrivileges=true
DevicePolicy=closed
PrivateTmp=true
ProtectControlGroups=true
ProtectHome=true
ProtectKernelLogs=true
ProtectKernelModules=true
ProtectSystem=strict
RestrictSUIDSGID=true
SystemCallArchitectures=native
SystemCallFilter=sendmsg recvfrom sendto getpid prctl brk socket read stat openat rt_sigaction fstat bind close connect getsockname setpriority capset getpriority lseek mmap mprotect munmap access execve getuid capget arch_prctl gettid
RestrictRealtime=true
LockPersonality=true
MemoryDenyWriteExecute=true
Consistent interface that only works on one platform and uses all the platform specific commands imaginable to do things that have no reason to be platform specific. And it doesn't even play well with other parts of that same platform.
What specifically irks you about it? When I'm honest with myself, I realize my biggest objection to systemd was "change". I was comfortable with something, it changed, and I resisted it. Once debian finally gave out and switched to systemd, I saw the writing on the wall and drank the kool-aid. I haven't had any regrets.
I feel like it was mostly a missed opportunity to do things better; the declarative unit stuff is both over and underspecified, and for anything nontrivial, I always end up with sidecar scripts, anyway, which makes the whole thing just a game of useless boilerplate.
And then it started attempting to assimilate other daemons...
Like I said, it is what it is. But what it is is a barely competent make-work replacement for something that wasn't the worst problem in early-startup, anyway.
If others were similarly curious, the "/index.html" isn't pedantry, just navigating to "/" is a separate welcome page that shortly thereafter redirects to the freedesktop.org site
If the boot-loader is meant to decrypt the root fs however, it won't be trivial and GRUB might be the best bet. At least it isn't listening on network ports ...
I think the initial presentation of systemd as a faster init system hurt it more than helped, because people started to think that systemd "was just an init system". And it never was really, even early on there were blog posts showing how powerful was its declarative approach. But it seems that the only blog post people remember is the "faster init" one (that even this one did more emphasis on the fact that systemd did dependencies the right way them the fact that it was fast).
> every other approach and dragging linux further away from its BSD/Illumos cousins
The way I think about systemd is that it make it closer to the approach of BSD and other *nix systems does. Portability is never something easy, specially when you're doing complicated things like power or network management. A good example is that all the different BSDs have difference between on how you manage networks, and the way it was on Linux before systemd was that *every* distro reinvented their own network management system (and each one was slightly broken in some fun way).
So what systemd does? They standardized everything. Now if your distro uses systemd-networkd, you can finally write a service that depends on a specific network topology that is portable across multiple Linux distros.
BSD don't need something like systemd because they're already tightly integrated, because the kernel and user space is both developed by the same team. Each part of a Linux user space used to be developed by different people, and it was the work of the distro to integrate everything. Now systemd provides a good foundation for many things in user space, and most distros stopped to ship their own solutions except for package management and some other integration bits that they need for their specific purposes.
So if you say to me that systemd is feature creep, it is as much feature creep them the whole FreeBSD or OpenBSD. And this just doesn't make sense.
For example, right now neither my desktop nor my notebook uses `systemd-networkd` and it works fine. Actually, since I use NixOS even basic things like `hostnamectl` or `timedatectl` are "disabled" (they work in read-only mode since those configs are managed by NixOS). But I do use `systemd-bootd` (so I can get boot information from the early UEFI until user space, try doing the same thing with GRUB+sysVinit).
The only two components that I know it can't be disabled in systemd is the init part and journalctl (because all the other parts of systemd depends on it).
The thing is, you want service management here. Sway is not a service manager and won't handle monitoring of the processes, socket activation, logging, etc.
If you ever try to port systemd code to non-Linux platforms you will see that this is not true. There are lots of things in Linux that have no real analog on other platforms, and it seems strange to fault a project for taking advantage of those. (BSD is the same way when you get into that too)
For example mysqld_safe is there pretty much to handle things that systemd can do, but initd can't. Some other services have custom wait-logic to make sure dependencies are ready, which is covered by service readiness notification in systemd (see just yesterday https://news.ycombinator.com/item?id=25845143). Many services do custom pidfile handling (see the fun implementation in openssh init file - your pidfile path better not have `=` in it) just because initd has no idea of services.
Basically every service I've seen which has more than a single line in start and stop functions in broken is at least one subtle way. (and close to every single status function - no, existence of the pidfile and that pid running an undefined process is not the same as service functioning) Systemd provides 99% of what those init scripts try to achieve as simple configuration and if something's missing you can still fall back to executing a script instead.
If you do trust Google, this is of no benefit. They encrypt your disk at rest anyway with their own keys if you don't provide yours.
The only reason to use any of the above tech is to change the legal burden of who has to provide data if a court order is made. If you provide the keys then the court has to come to you to provide data on demand.
Allowing the service providers to say "we don't have it", makes widespread government attack less scalable, because instead of focusing on one entity, suddenly they've got to chase down thousands of individuals and compel them. And the individuals usually have a lot less to lose if they don't obey than a tech company with billions on the line.
Exactly, but so can Intel/AMD/Dell/HP/$HW_VENDOR. That's why we have libreboot and friends trying to disable ME and other firmware blobs.
You could airgap your hardware in a SCIF and shred it when you're done with it but as stuxnet and other attacks have shown if you want to do useful network computing you can't be totally secure.
And screw unit files. Is there a helper utility to write and place the unit files for me? That would make me actually shutup about systemd.
I am honestly surprised we haven't seen a good GUI pop up around systemd yet that allows for simple service creation and configuration like that.
On the other hand, one really nice thing is that FIDO lets you force employees to actually use organisation mandated security if that's appropriate. There's no way to force the remote SSH client not to store that RSA private key unencrypted, for example, even if it is company policy to use a 16 character passphrase; but if you issue every employee a Yubikey (picking one famous brand) the FIDO authentication step can insist that a genuine Yubikey was used, that the Yubikey says a PIN was entered and user presence confirmed. The OpenSSH design passes the digitally signed assurance from the Yubikey to the remote server for assessment, so you can't just comment out a few lines of SSH client code to bypass it.
Should you actually do that? Probably not, but it's an option you didn't have before. Certainly if your key people already swear they obey a policy requiring this there's no harm in enforcing it, is there?
But there is a way to remotely attest that the private key has been generated on device (either through TPM attestation or https://developers.yubico.com/PGP/Attestation.html ).
Not to mention that the admin could just generate private keys on the token and give employees that.
I'm talking about being able to rule out causes because the primary components of the system are independent of each other.
The binary format doesn't matter for browsing logs. Replace `cat /your/custom/service/file.log | grep ...` with `journalctl -u service | grep ...` (or just `-a` for everything)
I'd actually argue it's easier not to mess up with journal with simple tools, because you don't have to special-case `service`, `service.1`, `service.2.gz` files.
Just turn on reader-mode in your browser. Or prefix the url with `about:reader?url=`.
> that shortly thereafter redirects to the freedesktop.org site
Specifically, it redirects to the systemd documentation part of the freedesktop.org site. There's also a bunch of other documentation redirects for the stuff I use. That's what index.html describes.
Try finding the documentation online to write a systemd service. Google finds tons of useless results and good luck remembering the freedesktop.org URL for systemd documentation (or even knowing that it's the _freedesktop.org_ link that is authoritive), or try navigating their landing page. It's a f#$%ing nightmare!
Just go here instead. https://systemd.software/service. Super short and easier to remember and easier to discover than `man service` oh wait I mean `man systemd` wait no I actually mean `man systemd.service` because `man systemctl`. Wait where do I even put the .service file???
The correct page is literally the first result on ddg and google for `man systemd.service`, or even just `systemd.service`. Same for all the other `systemd.*`
This isn't even new; I've been searching `man systemd.service` and `man systemd.socket` for years to reach those same pages.
If you search for `man service` you get linked to SysV init scripts [0] and are led astray if you don't know that sysv init scripts aren't systemd.
If you search for `man systemd` you get linked to a huge man page [1] which isn't approachable to a novice. There isn't an `EXAMPLE` section like there are on other man pages and searching for `example` doesn't reveal any commands to run. It doesn't describe where you can find an example service (unless you magically know that a "system unit" is a service and there's even a gotcha to that: it doesn't have a `files` section to describe where files are at (contrast with `man ssh_config` or `man nginx`) and it is absolutely not clear that the directory is hidden behind an obscure `pkg-config` invokation. Good luck discovering other services you can learn from by reading their service files!
If you managed to do `man systemctl` [2] you reach equally poor documentation. Again, no `files` section and this time not even a mention of `pkg-config`. There's a ton of mentions of environment variables (why does the _system_ need environment variables???). It describes how to "list" units but doesn't describe that it _won't_ list your user units (or, won't list the system units if you do --user). It doesn't describe how to _create_ a unit. It doesn't clearly walk you through the steps (again, there are no examples) so it's up to you to figure it out and hope you don't fuck up your system.
If you search for "just" `systemd`, you arrive at systemd.io [3]. Again, this site is not approachable to a novice! There's just lots and lots of reading. A _lot_ of reading. There's a few "examples" scattered everywhere in the form of an example command to run and a description of what it does. But _nowhere_ is there a single example with everything tied together into a single Hello World style solution.
[0] https://linux.die.net/man/8/service
[1] https://man7.org/linux/man-pages/man1/systemd.1.html
Another solution in the same space is Clevis[1]; last time I was researching this problem, I came across it via Red Hat's docs[2].
[1]: https://github.com/latchset/clevis
[2]: https://access.redhat.com/documentation/en-us/red_hat_enterp...
edit: early-ssh is hosted at https://github.com/gheja/early-ssh . Not to knock early-ssh by saying it's difficult to work with too - it's a great piece of software which has made my life a lot easier.
Disclosure: I'm a contributor.
Yeah, because that's the thing you want help with.
No shit `man service` and `man systemd` aren't going to give you help for systemd services that easily.
Also, apparently you assume the user is simultaneously stupid enough to not put "systemd" and "service" in the same search query, but is meant to know to visit `https://systemd.software/service` even though it too contains both those words.
No it isn't. I, as a power user and only as a novice system administrator, want to "run a program at startup".
It's not clear to me that it's `systemd` that manages that. It's not clear to me that it's specifically `systemd.service` that I need to find help with.
> No shit `man service` and `man systemd` aren't going to give you help for systemd services that easily.
But... why???
> Also, apparently you assume the user is simultaneously stupid enough to not put "systemd" and "service" in the same search query
Yes, I do assume that because it describes me. I'm sorry you think I'm stupid though. Get off your high horse and start thinking of people with different experiences than yours.
> but is meant to know to visit `https://systemd.software/service` even though it too contains both those words.
Searching Google for `systemd service` puts a link to freedesktop.org with a very un-memorable URL. I didn't even understand that "freedesktop.org" is the authoritive site until a few weeks into learning systemd. I definitely won't remember to type in "freedesktop.org/software/" before trying to find systemd documentation. And I don't want to have to use Google as a relay every time I want to read the documentation for systemd.
So I made a site that does it for me.