Hi all, we are hiring a remote worker and will be supplying a laptop to them. The laptop will be running a Debian variant of Linux on it.

We are a small shop and this is the first time we have entrusted somebody outside of our small pool of trusted employees.

We have sensitive client data on the laptop that they need to access for their day-to-day work.

However, if something goes wrong, and they do the wrong thing, we want to be able to send out some kind of command or similar, that will completely lock, block, or wipe the sensitive data.

We don’t want any form of spying or tracking. We are not interested in seeing how they use the computer, or any of the logs. We just want to be able to delete that data, or block access, if they don’t return the laptop when they leave, or if they steal the laptop, or if they do the wrong thing.

What systems are in place in the world of Linux that could do this?

Any advice or suggestions are greatly appreciated? Thank you.

  • Max-P@lemmy.max-p.me
    link
    fedilink
    arrow-up
    78
    arrow-down
    2
    ·
    edit-2
    26 days ago

    You’ll first want to lock down the laptop with using the TPM so it only boots kernels signed by you, and also encrypt the drive using the TPM as the locking key so the key is only ever available to a kernel you signed. From there you’ll probably want to use dm-verity to also verify the integrity of the system or at least during the boot process.

    Then, on top of that, once online and the machine is still authorized to access that data, you download a key from a server under your control to unlock the rest of the drive (as another partition). And log those accesses of course.

    Then, when you want to revoke access to it, all you have to do is stop replying with the key whenever requested. That just puts a ton of hurdles to overcome to access the data once the server stops handing the key. They would have to pry out the key from the TPM to unlock the first stage and even be able to see how it works and how to potentially obtain the key. They could still manage to copy the data out while the system is fully unlocked and still trusted, which you can make a lot harder by preventing access to external drives or network shares. But they have physical access so they kind of have the last word if they really really really want to exfiltrate data.

    This is the best you can do because it’s a passive: you stop supplying the unlock key so it’s stuck locked encrypted with no key, so the best they can do is format the laptop and sell it or use it for themselves. Any sort of active command system can be pretty easy to counter: just don’t get it online if you suspect the kill signal is coming, and it will never come, and therefore never get wiped. You want that system to be wiped by default unless your server decides it’s not.

    • sudneo@lemm.ee
      link
      fedilink
      arrow-up
      57
      ·
      26 days ago

      This is honestly an extremely expensive (in terms of skills, maintenance, chance of messing up) solution for a small shop that doesn’t mitigate at all the threats posed.

      You said correctly, the employee has the final word on what happens to the data appearing on their screen. Especially in the case of client data (I.e., few and sensitive pieces of data), it might even be possible to take pictures of the screen (or type it manually) and all the time invested in (imperfect) solutions to restrict drives and network (essentially impossible unless you have a whitelist of IPs/URLs) goes out the window too.

      To me it seems this problemi is simply approached from the wrong angle: once the data is on a machine you don’t trust, it’s gone. It’s not just the employee, it’s anybody who compromises that workstation or accesses it while left unlocked. The only approach to solving the issue OP is having is simply avoiding for the data to be stored on the machine in the first place, and making sure that the access is only for the data actually needed.

      Data should be stored in the company-controlled infrastructure (be in cloud storage, object storage, a privileged-access workstation, etc.) and controls should be applied there (I.e., monitor for data transfers, network controls, etc.). This solves both the availability concerns (what if the laptop gets stolen, or breaks) and some of the security concerns. The employee will need to authenticate each time with a short-lived token to access the data, which means revoking access is also easy.

      This still does not solve the fundamental problem: if the employee can see the data, they can take it. There is nothing that can be done about this, besides ensuring that the data is minimised and the employee has only access to what’s strictly needed.

    • Tobias Hunger@programming.dev
      link
      fedilink
      arrow-up
      23
      arrow-down
      1
      ·
      26 days ago

      If you find a reliable way to allow for people to use data without being able to copy it: Patent it right away, the entertainment industry will be paying big time for it.

      Same for erasing the laptop: You can only erase something as long as you can talk to the machine in some way to instruct it to clean itself up. The guy with the machine in hand can just turn off wifi to stop it from receiving the message…

      • Max-P@lemmy.max-p.me
        link
        fedilink
        arrow-up
        8
        ·
        25 days ago

        That’s why I focused on platform security. You can’t fully eliminate the possibility, but you can make it as hard as possible to pull off. TPM+dm-verity is to make it hard for the user to even look at how it works and prevent filesystem modifications that would give them root access to intercept the key loading mechanism.

        The part where the laptop continuously check and refreshes the key is to address the second part about just turning off WiFi: make it so if you do that, you have N hours to break the system open before it reboots itself and you’ve lost access to the key for good. This can also depend on hardware-backed checks like TPM measurements and signature, to make sure the data key is only handed over to the expected environment.

        It’s the same fundamental principles as Android and Play Integrity: use the security processor to attest the state of the device before the server agrees to send you stuff over. It’s been worked around via leaked keys mostly because Google is lenient for older devices, but the actual secure enclave hasn’t been broken yet.

        The point is for the security to hold long enough the key’s gone before they can get it, and without the key the laptop is effectively wiped. That’s plenty for the overwhelming majority of “employee got fired and is pissed off and wants to retaliate”, and the best that can be done without going remote desktop/VDI.

    • acockworkorange@mander.xyz
      link
      fedilink
      arrow-up
      5
      ·
      25 days ago

      I’d add a dead man switch thing that, if the laptop doesn’t get the key in X days, it erases the safe partition anyway. Of course the company would want all that data backed up in their servers all the time.

    • AndrasKrigare@beehaw.org
      link
      fedilink
      arrow-up
      3
      ·
      25 days ago

      I’m not the most up to speed on TPM’s, but does it have the capability to directly do network access in order to pull the key? Otherwise, you’re going to need the regular OS to get it to the TPM somehow, in which case that’s the weak link to pull the key instead of ripping it from the TPM itself.

      And once they have the key once, how do you enforce them having to re-request it? Is there a reason that that point they couldn’t just unplug from the Internet (if even necessary) and copy the entirety of that drive/partition somewhere else?

      • Max-P@lemmy.max-p.me
        link
        fedilink
        arrow-up
        5
        ·
        25 days ago

        No, that’s why signed kernel+initramfs+LUKS+dm-verity: protect the boot process all the way into userspace where you do have network access. From there you can request the TPM signs messages with a preloaded key it will only allow using it if you went through the whole secure boot process. It’s exactly what Android does with Play Integrity and the strong integrity flag.

        That way you can prove to the server that the computer is still secured and untampered with up to that point, which means the script that deals with the periodic checkin should be running untampered as well. If you’ve secured down the Linux install appropriately, it should be impossible for the user to gain enough privileges to request the key again from the TPM or extract the data key out of the mounted filesystem. That also means you can trust the system to block mounting any drives, force VPN on, make sure your MDM runs, all that stuff.

        You can reset the BIOS, boot from USB, all that stuff still, but then it would also wipe the TPM and so the OS no longer bootable, and obviously no signed TPM messages either so even if you find the script and how it works, at that point you don’t have the ability to sign the messages so the server won’t give you the data partition’s key either. The moment you tamper with it, it breaks the trust chain and the keys are gone. Can’t flip a single bit on the system and boot partitions without the checks failing.

        It’s not bulletproof, some laptops you can sniff the TPM bus in minutes due to design flaws, but in theory as long as the hardware holds it’s pretty secure. And obviously you can always just take a picture of the screen, no avoiding that. But it puts enough hurdles it’ll stop most opportunistic exfiltration. One bad move and you wipe the keys, so you better know exactly what you’re dealing with or you have one embarassing and incriminating email to write to IT to have them reprovision the keys.

        • AndrasKrigare@beehaw.org
          link
          fedilink
          arrow-up
          2
          ·
          25 days ago

          Ah, gotcha, I was thinking more in terms of software attacks than hardware, and that some vulnerability would come up at some point for them to get root access, at which point I think they’d be able to get the key one way or another. I’d imagine it also depends on how locked down the system can be based on the nature of their duties; arbitrary internet access makes shipping it off somewhere a bit easier. Another consideration would be that the drive could also be imaged, and if the key were ever recovered at a later date through whatever method/mistake/etc. the entirety of the data could be recovered.

          But, yeah, definitely agree that that’s all moving well outside the bounds of disgruntled/opportunistic employee and more into the persistent adversary realm.

  • egonallanon@lemm.ee
    link
    fedilink
    arrow-up
    69
    ·
    25 days ago

    If the data is sensitive just give them a cheap whatever machine and have them connect to a vdi. That way the data never leaves your estate and means you don’t have to worry as much about the device being lost/stolen. If this isn’t an option I’d strongly recommend looking into an MDM solution for your devices.

  • notabot@lemm.ee
    link
    fedilink
    arrow-up
    40
    arrow-down
    1
    ·
    25 days ago

    There is a fundamental issue with this approach: the rogue employee has already copied the data to a USB drive by the time you try to wipe it.

    If the data is confidential, you either need to set up standard disk encryption and trust the employee, or not let them access it in a way it can be bulk copied. For instance, might it be possible for them to use a webapp that you control access to or a remote desktop type setup?

    • dan@upvote.au
      link
      fedilink
      arrow-up
      7
      ·
      edit-2
      25 days ago

      A lot of employers (at least the larger ones) block USB drives and have software to monitor for data exfiltration - monitoring where files are copied to, usage of copy/paste in browsers, etc.

      You should always assume that your work devices are being monitored.

      • notabot@lemm.ee
        link
        fedilink
        arrow-up
        2
        arrow-down
        1
        ·
        25 days ago

        I agree that you should assume you’re being monitored, but, while that helps against malware type exfiltration, it does little to stop someone who is determined to exfiltrate the data as there are a myriad of ways to do so that aren’t possible to monitor, such as simply taking a video of the screen whilst displaying the information.

        Ultimately, the company has to trust the employee or not give them access to the sensitive data, there’s no middle ground.

        • PowerCrazy@lemmy.ml
          link
          fedilink
          English
          arrow-up
          2
          ·
          25 days ago

          This is fundamentally true. However it is possible to limit the bandwidth of data the employee can exfiltrate.

          Assuming a privileged employee suddenly becomes a bad actor. Private-keys/certs are compromised, any kind of shared password/login is compromised.

          In my case I have a legit access to my company’s web-certs as well as service account ssh-key’s, etc. If I were determined to undermine my company, I could absolutely get access to our HSM-stored software signing keys too. Or more accurately I’d be able to use that key to compile and sign an arbitrary binary at least once.

          But I couldn’t for example download our entire customer database, I could get a specific record, I could maybe social engineer access to all the records of a specific customer, but there is no way I’d be able to extract all of our customers via an analog loophole or any standard way. The data set is too big.

          I also wouldn’t be able to download our companies software source code in it’s entirety. Obviously I could intelligently pick a few key modules etc, but the whole thing would be impossible.

          And this is what you are trying to limit. If you trust your employees (some you have to), you can’t stop them from copying the keys to the kingdom, but you can limit the damage that they can do, and also ensure they can’t copy ALL the crown jewels.

          • notabot@lemm.ee
            link
            fedilink
            arrow-up
            2
            arrow-down
            1
            ·
            25 days ago

            This is fundamentally true. However it is possible to limit the bandwidth of data the employee can exfiltrate.

            That’s fair, but the OP was talking about having the sensitive data directly on the laptop, which rather limits your ability to control access to it, and why I was suggesting keeping the data on a server and providing access that way, so limits can be put in place.

            Assuming a privileged employee suddenly becomes a bad actor.

            Your threat model probably isn’t the employee who suddenly goes rogue and tries to grab everything, but the one who spends and extended period of time, carefully, extracting key data. As you, the former can be be mitigated against, but the latter is very much harder to thwart.

            But I couldn’t for example download our entire customer database, I could get a specific record, I could maybe social engineer access to all the records of a specific customer, but there is no way I’d be able to extract all of our customers via an analog loophole or any standard way. The data set is too big.

            That’s well set up, but, whilst your competitor would love the whole database, what they’re really interested in is the contact details and contract information for maybe your largest three customers. When the dataset to extract is small enough, even quite advanced rate limiting can’t really help much. Making sure no one person has access to all of the most valuable data is a good start, but can present practical problems.

            And this is what you are trying to limit. If you trust your employees (some you have to), you can’t stop them from copying the keys to the kingdom, but you can limit the damage that they can do, and also ensure they can’t copy ALL the crown jewels.

            I think we’re basically saying the same thing. The OP talked about putting all the sensitive information on the employee’s laptop, and that’s what I was trying to steer them away from.

            In the past I’ve been asked if we can provide our developers access to pull the full source tree, but not copy it anywhere, and, to quote Charles Babbage, “I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.”

            I enjoy the security side of sysadmin work, but I find it rather depressing, as all you can hope to do is lose slowly enough that it’s not worth attacking you.

  • Nibodhika@lemmy.world
    link
    fedilink
    arrow-up
    35
    ·
    25 days ago

    Realistically the best option here is to not have the data in the laptop. So they would remote into a machine you control to access the data, or something of the sort. Regardless the laptop should have full disk encryption so if it gets stolen no data is accidentally leaked.

    Other than that the best way I can think of is giving the user a non-root account and have the laptop connect to tailscale automatically so you can always ssh into it and control it if needed. But this is not ideal, because a malicious person could just not connect to the internet and completely block you from doing anything. This is true for almost any sort of remote management tool you would be able to find.

    • LovableSidekick@lemmy.world
      link
      fedilink
      English
      arrow-up
      2
      ·
      edit-2
      25 days ago

      First part is what I was thinking - have the sensitive data on a server for the laptop to access. Of course an unscrupulous user can always save any data they want. But it’s totally normal for companies to give temp employees access to their internal data. Their standard method of protection is to make the person sign an NDA. The threat of expensive legal action deters most people from violating it.

    • OsrsNeedsF2P@lemmy.ml
      link
      fedilink
      arrow-up
      33
      ·
      26 days ago

      +1 for going with a third party on something like this. Your small shop is an expert in whatever they’re doing, don’t try and recreate someone else’s buisness thinking it will be easy

    • sudneo@lemm.ee
      link
      fedilink
      arrow-up
      4
      ·
      26 days ago

      Useful for standardized management of fleets, but requires personnel to maintain and configure it, but I don’t think it’s very effective (or feasible - I doubt they will even join the call for a 1-device contract) for what OP needs.

  • dan@upvote.au
    link
    fedilink
    arrow-up
    32
    arrow-down
    1
    ·
    25 days ago

    As someone else said, I’d go with an MDM vendor instead of trying to build something yourself.

    The most secure thing would be to have the person connect to a remote server and do all their work on the remote server, essentially just using the laptop like a thin client.

    • mub@lemmy.ml
      link
      fedilink
      arrow-up
      9
      arrow-down
      4
      ·
      edit-2
      25 days ago

      This is the only reliable solution. To expand:

      1. Provide a Laptop with Windows on it, because that is easier to lockdown.
      2. apply desirable OS lock downs like blocking usb ports prevent storage devices, don’t give the user admin rights, etc.
      3. Setup a VPN server (openvpn should do) and configure the laptop with a VPN client. Configure the client so it blocks network connections that don’t go via the VPN. If you want to give them internet access you’ll need a proxy and firewall and DLP solution. At this point it all gets very complex and expensive.

      The real answer is you are probably screwed without investing a bunch of time, effort, and cost.

      You might get away with more basic security measures if the user has very limited IT knowledge.

      I suggest getting legal advice before you give the user access to your data in the manner you intend.

      • sudneo@lemm.ee
        link
        fedilink
        arrow-up
        3
        ·
        24 days ago

        DLP solutions are honestly a joke. 99% of the case they only cost you a fortune and prevent nothing. DLP is literally a corporate religion.

        What you mentioned also makes sense if you are windows shop running AD. If you are not, setting it up to lock 1 workstation is insane.

        Also, the moment the data gets put on the workstation you failed. Blocking USB is still a good idea, but does very little (network exfiltration is trivial, including with DLP solutions). So the idea to use remotely a machine is a decent control, and all efforts and resources should be put in place to prevent data leaving that machine. Obviously even this is imperfect, because if I can see the data on my screen I can take a picture and OCR it. So the effort needs to go in ensuring the data is accessed on a need basis.

        • mub@lemmy.ml
          link
          fedilink
          arrow-up
          1
          ·
          edit-2
          24 days ago

          That was kinda my point. Securing a laptop that will have access to data you want to protect from loss is a near bottomless pit of issues. There comes a point you have to do a risk assessment and apply a level of security that meets your legal requirements and contractual obligations. I’m sure this is all doable on Linux as well but the low cost / easily available tools are mostly for Windows.

          I suspect that taking the “secured remote session” approach is probably good enough for their needs. It just needs a client app you can trust to respect the security rules they want to enforce (no screen shots, no screen recording, no data transfers for any sort, etc).

          OCRing what is on screen is not really stoppable unless you force them to keep their camera on so you can monitor them 24/7. But if you try hard enough there is usually a way around most security measures.

          Either way, they need to decide what the risk impact vs likelihood profile is, and what the business can tolerate. They’ll need to discuss it with legal and data protection folks to assess that.

          One tip is to embed records and values that look meaningful, but are unique, into the copy of the data given to the specific employee. This can be used to potentially prove that a data breach was a result of something that employee did. We like to put QUID’s as invisible watermarks in document headers. These trigger our DLP systems which is always funny cos its usually an employee who is leaving and wants to keep something. I love those conversions.

          • sudneo@lemm.ee
            link
            fedilink
            arrow-up
            2
            ·
            24 days ago

            I like the idea of canaries in documents, I think is a good point but obviously it only applies to certain types of data. Still a good idea.

            Looking at OP, they seem a small shop, with a limited budget. Seriously the best recommendation I think is to use some kind of remote storage for data (works as long as the employee complies) and to make sure the access control is done in a decent way (reducing the blast of employee behaving maliciously). Anything else is probably out of reach for a small company without a security department.

            Maybe I sounded too harsh, that’s just because in this post I have seen all kinds of comments who completely missed the point (IMHO) and suggested super complicated technical implementations that show how disconnected some people can be from real technical operations, despite the good tech skills.

      • horse_battery_staple@lemmy.world
        link
        fedilink
        arrow-up
        2
        ·
        24 days ago

        Windows is absolutely more difficult to secure than linux. I can restrict access down to the kernel level in linux. Windows has no such granularity

        • mub@lemmy.ml
          link
          fedilink
          arrow-up
          1
          ·
          24 days ago

          “Easy” from the point of view there a lots of off the shelf tools to help you do it that are easy to understand.

          • horse_battery_staple@lemmy.world
            link
            fedilink
            arrow-up
            2
            arrow-down
            1
            ·
            24 days ago

            That Crowd strike outage was pretty evident of how easy windows is to secure. Linux had the same failure but since admins are able to secure the OS in a more granular way and can update packages in situ without touching the registry, Linux users could still boot into their OS and patch the broken file. No such luck in Windows.

            • Charzard4261@programming.dev
              link
              fedilink
              arrow-up
              2
              ·
              24 days ago

              Windows users could boot into safe mode and modify/delete the problem file. There just wasn’t any tool to roll out this fix ‘automatically’.

              Once IT dealt with it I stopped paying attention to the situation, but I wonder if any tool was created to help the poor souls managing thousands of PCs?

              • 🜏 Jyan 잔 🜏@4bear.com
                link
                fedilink
                arrow-up
                1
                ·
                24 days ago

                @Charzard4261 @horse_battery_staple , any compute running Crowdstrike, Bitlocker, and no remote access during the prebooted environment would certainly require manual intervention. Also, all those Bitlocker keys having to be manually inserted for computers that required physically being present? Hell in a shell.

                • horse_battery_staple@lemmy.world
                  link
                  fedilink
                  arrow-up
                  1
                  ·
                  24 days ago

                  Absolutely this for windows. Linux however allowed crowdstrike to run without it being a boot time event. I administer a mixed environment. I worked 18 hours straight remediating that outage.

              • horse_battery_staple@lemmy.world
                link
                fedilink
                arrow-up
                1
                ·
                24 days ago

                No. If the device was encrypted it had to be done locally. Laptops had to either be wiped and restored to backup or a sysadmin had to reset the machine locally with a local admin. There was no remote remediation possible unless the sysadmin gave the user a local admin account and password.

                On Linux I was able to push the new file over the network and reboot the machine.

                On windows companies were shipping laptops or restoring to backups.

                • mub@lemmy.ml
                  link
                  fedilink
                  arrow-up
                  1
                  ·
                  24 days ago

                  I dual boot windows and EndeavourOS. Every 6 to 12 months I make a concerted effort to make the switch 100% but it hasn’t worked out yet. So while Linux is great windows is unavoidable. In this use case I suspect managing Windows tools will be simpler, though I agree that effectiveness next to Linux options won’t be equal.

  • Phoenixz@lemmy.ca
    link
    fedilink
    arrow-up
    28
    ·
    24 days ago

    You need a legal solution, not a technical.

    What you’re asking for is an mdm solution, but once a user has access to data, that user can copy it whether you like it or not, whatever mdm solution you use.

    Even if you lock down everything, break the USB ports physically, I can photograph the screen, for example.

    This has been an age old problem and honestly mdm tools are kind of a hammer where you need a screw driver. It advertises a lack of trust on your end, adds a lot of complexity and potential usability problems and in the end will still never be able to protect you 100%

    Go for a legal option and find people you can trust. Also know that 100% security does not exist. The only 100% secure computer is off and on fire.

  • 0x0@programming.dev
    link
    fedilink
    arrow-up
    16
    ·
    26 days ago

    However, if something goes wrong, and they do the wrong thing, we want to be able to send out some kind of command or similar, that will completely lock, block, or wipe the sensitive data.

    You’re assuming you’ll have a network connection and that sensitive data is all in the same place.

    Short of remotely unlocking an encrypted disk on every single boot… and even then…

  • asudox@discuss.tchncs.de
    link
    fedilink
    arrow-up
    10
    ·
    25 days ago

    The best option is to never trust anyone. Depending on how the info is supposed to be used, you can setup a website that does those important things with the sensitive data (stored on the server) without exposing the sensitive data to the user.

  • BilboBargains@lemmy.world
    link
    fedilink
    arrow-up
    10
    arrow-down
    1
    ·
    25 days ago

    You need to find someone you trust. There’s no technology that can prevent someone disclosing data if it’s their job to work with that data.

    If you treat people with respect and pay them well, you will be amazed at what they give back. Especially autistic people, they tend to have high personal integrity.

  • AndrasKrigare@beehaw.org
    link
    fedilink
    arrow-up
    7
    ·
    edit-2
    25 days ago

    Fundamentally, once someone has some of the data, they have that data, and you can make no guarantees to remove it. The main question you need to ask is whether or not you’re okay with limiting it to the data they’ve already seen, and what level of technical expertise they need to have to keep the data.

    Making some assumptions for what’s acceptable as a possibility, and how much you want to invest, I’d recommend having the data on a network-mapped share, and put a daily enforced quota for their access to it. Any data they accessed (presumably as part of their normal duties) is their’s, and is “gone.” But if you remove their access, they can’t get any new data they didn’t touch before, and if they were to try and hoover up all the data at some point to copy it off, they’d hit their quota and lose access for a bit (and potentially send you an alert as well). This wouldn’t prevent them from slowly sucking out the data day after day.

    If they only need to touch a small fraction of the customer data, and particularly if the sensitivity of the data goes down over time (data from a year ago is less sensitive than data from a day ago) this might be a decent solution. If they need to touch a large portion of the data, this isn’t as useful.

    Edit: another nice bit is that you could log on the network share (at your location) which of the customer data they’re accessing and when. If you ever want to audit, and see them accessing things they don’t need, you can take action.

    I think the next best solution is the VDI one, where you run a compute at your location, and they have to remote into it. If they screen capture, they’ll still save off whatever data they access, and if they have poor, or inconsistent, connection up your network it’ll affect their ability to do their job (and depending how far away they are it might just be super annoying dealing with the lag). On top of that, it’s dependent on how locked-down they need to be to do their job. If they need general Internet access, they could always attempt to upload the data somewhere else for them to pull it. If your corporate network has monitoring to catch that, you might be okay, but otherwise I think it’s a lot of downside with a fairly easy way to circumvent.

  • boredsquirrel@slrpnk.net
    link
    fedilink
    arrow-up
    3
    arrow-down
    1
    ·
    edit-2
    26 days ago
    • use a non sudo user for the user
    • somehow get the IP address of that laptop all the time. There are dynDNS solutions like this where the client just needs to automatically download a certain file daily and you know his IP, my implementation is here.
    • have ssh access to root with a ssh key. The usual hardening, fail2ban, block using passwords
    • open the port for ssh on the clients system

    If something goes wrong, login via ssh (you know the dynamically changing IP) and remove a directory or the entire user.

    You cannot avoid that a user would copy files from there to a usb stick. Well you could, by using usbguard. Works really well in my experience, just prevent nonsudo users from adding new devices.

    And then you need to prevent the user from booting another system, or taking out the SSD and reading it. TPM and boot lock is the right thing here, what Max-P wrote.

    • sudneo@lemm.ee
      link
      fedilink
      arrow-up
      8
      ·
      26 days ago

      Your ability to SSH in the machine depends on the network connectivity. Knowing the IP does nothing if the SSH port is not forwarded by the router or if you don’t establish a reverse tunnel yourself with a public host. As a company you can do changes to the client device, but you can’t do them on the employee’s network (and they might not even be connected there). So the only option is to have the machine establish a reverse tunnel, and this removes even the need for dynamic DNS (which also might not work in certain ISPs).

      The no-sudo is also easier said than done, that means you will need to assist every time the employee needs a new package installed, you need to set unattended upgrades and of course help with debugging should something break. Depending on the job type, this might be possible.

      I still think this approach (lock laptop) is an old, ineffective approach (vs zero-trust + remote data).

      • 8adger@lemmy.world
        link
        fedilink
        English
        arrow-up
        3
        ·
        25 days ago

        You could implement a ssh tunnel every time it is online. Then you just use a reverse tunnel through that connection.

        • sudneo@lemm.ee
          link
          fedilink
          arrow-up
          1
          ·
          25 days ago

          Yeah, that’s what I wrote too, but that is still a very fragile way. For once, you depend on a network connections, or in the local firewall not blocking you etc.

          Reactive, on-demand ssh is something you can do for tech support, not for security imho.

      • boredsquirrel@slrpnk.net
        link
        fedilink
        arrow-up
        1
        ·
        25 days ago

        True, forgot about that.

        Alternatively yeah some system to load the data online, autodelete after a while of not logging into something.

        But the question really is “why?”

        Disk encryption should deal with everything. Secure boot and usbguard are useful anyways.

        • sudneo@lemm.ee
          link
          fedilink
          arrow-up
          1
          ·
          25 days ago

          Disk encryption is a control against lost or stolen device and malicious physical access (kinda). Storing the data elsewhere is more a control (or the basis for controls) against malicious insiders.

  • mvirts@lemmy.world
    link
    fedilink
    arrow-up
    3
    arrow-down
    1
    ·
    24 days ago

    I second the idea that this is a bad idea, but…

    Maybe a remote desktop solution is what you want, keep your data local or in your cloud account and provide remote access to a machine that can use it?

    You could roll your own self destruct script that will wipe the machine on boot if it hasn’t phoned home in a while. You would want to lock the bios and use secure boot. Qubes may have some relevant features.

    Also, consider getting a Chromebook instead. ChromeOS is already a walled garden and I think they are remote wipeable and they can run a Linux vm supported by elgoog.

    • sudneo@lemm.ee
      link
      fedilink
      arrow-up
      1
      ·
      24 days ago

      Jamf doesn’t do anything for this problem, besides costing you a fortune in both license and maintenance/operation. Especially if you are not a Mac shop.

      MDM at most can be used as a reactive tool to do something on the machine - as long as the one with the machine in their hand leaves the network connection on.

      There are much cheaper solution to do that for 1 machine, and -as others correctly pointed out- the only solution (partial) here is not storing the data on a machine you don’t control. Period.