Announcement

Collapse
No announcement yet.

Systemd Working On "Storage Target Mode" Feature - Inspired By Apple macOS

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by kenjo View Post
    maybe but don't we solve this paticular problem with a bootable USB stick ?
    In a remote DC, with many tens of thousands of systems, remote hands (to plug in that mythical USB stick) is not always a easily schedulable resource (if they are available at all). While most times any single system that goes offline is immaterial to the operation (if you are doing it right), having a remote way to boot into target mode would be a nice tool in the toolbox for those special cases where you need to recover a specific system right now. I can also see some value in some specific forensic scenarios.

    Comment


    • #22
      Originally posted by QwertyChouskie View Post

      If an attacker can pass arbitrary boot flags, you probably have bigger issues.
      If you give an attacker the ability to access your system and pass arbitrary boot flags, my Gods, I'm sure you have bigger issues, too.

      Comment


      • #23
        This has to be the most positive systemd thread ever lol

        Comment


        • #24
          Originally posted by CommunityMember View Post

          In a remote DC, with many tens of thousands of systems, remote hands (to plug in that mythical USB stick) is not always a easily schedulable resource (if they are available at all). While most times any single system that goes offline is immaterial to the operation (if you are doing it right), having a remote way to boot into target mode would be a nice tool in the toolbox for those special cases where you need to recover a specific system right now. I can also see some value in some specific forensic scenarios.
          there is a number of solutions for that like ipmi, AMT, OPMA .....

          Comment


          • #25
            As a security person who just wrote a REALLY long document describing all the ways and tools one would need to do forensics on machines that might have HDDs, SSDs, or hard-to-get-at flash on strage form factors... this is welcome. I hope there's some way to protect the setting, but I don't mind if it has nothing to do with the volume encryption, which other tools would be used for. I just want to be able to connect USB-C up to a forensics rig and suck the drive's bits out with DD.

            Comment


            • #26
              Originally posted by waxhead View Post
              What Lennart cooks up here is actually interesting. I like systemd in general but not everything. Timers are not intuitive I think, mounts are unreadable and homed seems potentially messy, but this could be a fun little addition to our love/hate relationship. My main worries are potential attack vectors, but then again I know nothing about this feature except what is written here.
              It sounds like it’s going to reuse a lot of pre-existing functionality; just an isolatable target file with the minimum dependencies, UDev/device/network hooks, and a template service for each shared resource. SystemD can already create and manage sockets, so the only new functionality would be the transport of data/commands between the sockets and devices. I think that particular functionality should be relatively simple and straightforward to audit.

              I would argue that because it requires so few changes to core SystemD functionality, it really shouldn’t be part of the core SystemD project in the first place—but I think that’s true for a lot of existing components (like ResolveD, TimesyncD).

              Personally I think that timer and mount units are pretty readable and I tuitive, but I have a fair amount of experience with SystemD at this point.

              Comment


              • #27
                Originally posted by QwertyChouskie View Post

                If an attacker can pass arbitrary boot flags, you probably have bigger issues.
                It might currently only be available via boot arguments (I’m not sure), but I think it will eventually just be a target that you can isolate to (like multi-user.target or graphical.target). In both cases, masking the unwanted target should disable isolating to it, which would then disable that feature.

                Comment


                • #28
                  I'm pretty impressed not only by this feature, but also that the pull request consists mainly of configuration files and documentation. There is mainly one code change:
                  Code:
                  sd_event* sd_netlink_get_event(sd_netlink *nl) {
                          assert_return(nl, NULL);
                  
                          return nl->event;
                  }​
                  This shows how flexible and modular systemd is!

                  Comment


                  • #29
                    Originally posted by kenjo View Post

                    there is a number of solutions for that like ipmi, AMT, OPMA .....
                    I have yet to encounter a single one of those that can expose the remote server's block devices, some of them allow for mounting installation media from the admin side to the remote side but not the other way around.

                    Comment


                    • #30
                      Originally posted by X_m7 View Post
                      I wonder which devices would have such a controller, if any, and how one can check for the presence for such a controller. One of the comments in the PR mentioned the Raspberry Pi as an example (and I assume phones that support having flash drives and such plugged into them would also have one), but I'm more interested in whether devices like the Steam Deck or similar handhelds could support that feature, since booting into a live USB to fix things might be harder without a keyboard, mouse and/or dongle laying around for those.
                      Indeed, most SBC and smartphone support being devices.

                      Regarding the SteamDeck: Yes, it's possible to put it in device mode, and some people have managed to have it emulate a printer, and I know other people are interested in having it emulate a gamepad.

                      So emulating a USB flash stick is certainly doable.

                      Originally posted by cynic View Post

                      do you know of any bootable USB stick that does this already?
                      I'd like to have one to carry with me in my toolbox!​
                      On smartphones:
                      • JumpDrive is a postmarketOS-based SDcard booter that does exactly that.
                      • U-Boot has UMS mode and is compiled in some phones firmware (e.g.: on the TowBoot shipped with PinePhone Pro).


                      Given that JumpDrive is opensource and based on PostmarketOS, it means that it could be adapted on other hardware, as long as the kernel's USB driver supports putting the specific controller into target (device) mode.
                      e.g.: Somebody could make a SteamDeck JumpDrive boot SD card that makes the NVMe (or eMMC for those who bought the 64GB version) accessible over the USB-C port.


                      Originally posted by kenjo View Post
                      maybe but don't we solve this paticular problem with a bootable USB stick ?
                      Yeah and the idea is to have systemd as a simple way to bring that up on the linux running on the USB stick.

                      Also if it is a target, it means that:
                      • the necessary dependencies can be tracked and packaged into initramfs
                      • it is possible to fall back to that target automatically if you need to rescue, the same way lots of distro durrently fallback to maintenance mode ("Give root password for maintenance (or type Control-D to continue)​")

                      So it would be possible to remotely switch to that upon reboot or in case of boot failure.

                      Originally posted by kenjo View Post
                      there is a number of solutions for that like ipmi, AMT, OPMA .....


                      Yes. But those systems are often closed source, and very often vendor-specific, buggy (and often exploitable) implementations. (Usually, you only enable IPMI on a separate admin network, which is not internet connected).
                      Meanwhile systemd is the "less worse" solution, simply due to being opensource and more widespread among distros and thus more scrutinized by those distro devs.

                      Comment

                      Working...
                      X