[HN Gopher] Assume your devices are compromised
       ___________________________________________________________________
        
       Assume your devices are compromised
        
       Author : _wldu
       Score  : 116 points
       Date   : 2022-04-17 19:39 UTC (3 hours ago)
        
 (HTM) web link (www.go350.com)
 (TXT) w3m dump (www.go350.com)
        
       | ur-whale wrote:
       | air gapped tails running on a 1999 x86 box ftw
       | 
       | https://tails.boum.org/
        
       | motohagiography wrote:
       | Been doing this a long time. _The device is the compromise._
        
       | vmoore wrote:
       | I routinely prune /home of sensitive info, and often move secrets
       | into a Cryptomator or Veracrypt vault. I also compartmentalize my
       | workflow. One for NSFW stuff, another for work, another for
       | playing games, and the list goes on...I do this because a
       | compromise of one system does not mean a compromise of my entire
       | system. Virtual machines are great for this alongside
       | Chrome/Firefox profiles for different things. How you slice and
       | dice up your own system(s) is entirely up to you.
        
         | uxcolumbo wrote:
         | How do you compartmentalize?
         | 
         | With VMs or setting up different profiles?
        
       | walterbell wrote:
       | For workloads which don't require persistence (e.g. web
       | browsing), you can boot a PC from an external storage device with
       | write-blocking firmware. Kanguru sells flash, SATA and NVME
       | drives with a physical write-protect switch.
       | 
       | Are there good tools for anomaly/intrusion detection on Linux?
       | Even something as simple as comparing current resource usage with
       | a baseline record of disk/network/CPU utilization.
        
       | CameronNemo wrote:
       | Bought a desktop recently. Thought about setting up verified boot
       | and disk encryption, but...
       | 
       |  _[M]y biggest takeaway was that all of this was quite
       | complicated and did not really have anything to do with what I
       | bought this system for. So I decided to throw in the towel and
       | flip SecureBoot off._
       | 
       | (See last section here, on trust):
       | https://cameronnemo.gitlab.io/posts/lagomorpha/
        
       | vorpalhex wrote:
       | I struggle a lot with this.
       | 
       | Secure isn't a binary state, it's a spectrum.
       | 
       | At the same time, what is my risk model? Are my NSFW activities
       | THAT interesting? What about my personal notes that contain
       | health details?
       | 
       | I keep an inventory of stuff in my home. Is that ok to keep in
       | Dropbox? Sure the government can access it.. but even if a remote
       | attacker does, is that useful to them?
       | 
       | And of course, as things get more secure they become less
       | accessible. My "very secure" documents archive almost never gets
       | updated.. cuz it's a pain to update it. My daily notes are just
       | chucked in dropbox and get updated all day long...
        
       | digitallyfree wrote:
       | If this is the kind of protection you want you should be running
       | everything in seperate VMs and containers. Preferably you would
       | run the hypervisor (perhaps a hardened bare-metal hypervisor) on
       | your server and remotely connect to the instances with your
       | client. The client is solely used for connecting to those
       | instances.
       | 
       | The hypervisor itself will need to be well protected and you do
       | not want that accessible from your client or the VMs and
       | containers - use a seperate NIC or VLAN. This is the reason why
       | you want a seperate server - the only things the client will see
       | are the shared containers. Let's assume here that VMs and
       | containers are secure - if they aren't, you can replicate this
       | with seperate physical machines.
       | 
       | On the server you can set firewall rules to control access
       | between the different containers. Network storage etc. can also
       | be setup for the containers that need it, with different
       | permissions depending on the situation.
       | 
       | Depending on the stuff you are running, you may want to go the
       | VDI or SSH route. Also there are other options like XPRA, etc.
       | depending on your requirements. The more segmentation you do
       | (i.e. one VM for the dev envionment for a specific app, another
       | for chat and email, etc.), your security will increase at the
       | cost of usability.
       | 
       | I personally do this in a limited fashion (I have secure
       | workstations and VDIs for handling of private/financial
       | information), but do not go the full route of seperating
       | everything out for day-to-day computing.
        
         | privacyking wrote:
         | Or just use Qubes OS
        
       | Havoc wrote:
       | While true on a theoretical level this is largely impractical. To
       | quote House
       | 
       | >Cuddy: "How is it that you always assume you're right?
       | 
       | >House: "I don't, I just find it hard to operate on the opposite
       | assumption."
       | 
       | If you're on a personal desktop at home you've got to place some
       | level of trust in it.
       | 
       | Same with local LAN.
       | 
       | Once you get to more sophisticated server microservices then you
       | can start thinking of the various components as mutually
       | untrusted (until proven otherwise)
        
       | smitty1e wrote:
       | To that point, how many people run browser proxies in the cloud
       | to obfuscate their location and minimize the blast radius if
       | compromised?
       | 
       | One could filter much of the crapology somewhere safe, and then
       | have a relatively tidy local browsing experience.
       | 
       | I'm too busy to take this idea past the handwaving stage, but it
       | seems like someone should have already done the homework.
        
         | gruez wrote:
         | > I'm too busy to take this idea past the handwaving stage, but
         | it seems like someone should have already done the homework.
         | 
         | Indeed. https://www.mightyapp.com/
        
         | megous wrote:
         | I run the browser under different OS user accounts, and make my
         | display manager display the user account in the window title
         | bar.
         | 
         | https://megous.com/dl/tmp/8eaa15e187fa9a2e.png (ff1 being the
         | user)
         | 
         | I trust it more than browser's internal isolation solutions,
         | like tab containers, which I like to use for other things, like
         | testing web apps using different login sessions at once.
         | 
         | I'd hate a remote solution. ;) Though this is not for privacy
         | but more for protection and better low effort isolation.
        
       | daenz wrote:
       | These are fun thought experiments, but I think having a personal
       | Disaster Recovery plan is a far more applicable security
       | exercise. What would you do if you lost your phone? If you were
       | locked out of your google account? If you forgot your password
       | manager master password? If your home was destroyed in a fire?
       | Having a secure plan for quickly recovering from these scenarios
       | is more important than trying to keep state actors or cybergangs
       | out of your system, unless you are a VIP.
        
         | CameronNemo wrote:
         | _If you forgot your password manager master password?_
         | 
         | Short of brain damage, I don't think that would ever happen.
         | 
         | It would be a hassle for my family if I died, though. I'm
         | young, but I should still get that scenario worked out.
        
           | bbarnett wrote:
           | With a death certificate, you don't need passwords, or even
           | account numbers, to access savings, accounts at fiscal types
           | of businesses.
           | 
           | It helps pf course, to have account info, but just knowing
           | the place of business is typically enough.
           | 
           | For clarity, living people lose account numbers and access
           | all the time. The death cert. gives you this same power.
        
             | philjohn wrote:
             | Not for, eg, lastpass.
             | 
             | Your master password is the key that decrypts your password
             | vault.
             | 
             | Some sort of escrow would be good, that unlocks a document
             | with access instructions upon receipt of a valid death
             | certificate.
        
               | CamelRocketFish wrote:
               | Yes but lastpass contains your password to something like
               | your bank account. You don't need your password for your
               | bank account if you have a death certificate is what the
               | poster is saying.
        
           | inglor_cz wrote:
           | When I am on a longer vacation and I do not use a certain
           | password, I struggle remembering it.
           | 
           | If I were chucked into a prison and let out after several
           | years with no computer use in between, I would likely forget
           | all my passwords in the meantime. No brain damage needed,
           | just disuse.
        
         | phphphphp wrote:
         | I debate this with myself often. Short of renting a security
         | box and telling people I trust about it, I haven't come up with
         | a strategy for the master password. At the moment, I've
         | resigned myself to the feeling that if I lose my memory, maybe
         | it'll be the opportunity for a fresh start, and so losing
         | everything is a feature not a bug.
        
           | chrisweekly wrote:
           | I wrote mine down and put it in an envelope containing a few
           | other secrets in a small fire-resistant, waterproof safe
           | which my wife knows how to open.
        
             | CamelRocketFish wrote:
             | Which safe did you get?
        
           | usrn wrote:
           | I publish or write down most of the things I want to keep in
           | that scenario.
        
           | jvanderbot wrote:
           | Just send four trusted family members half of the passphrase
           | in a sealed envelope and tell them what it's for. If your
           | family has a lawyer or safe deposit box trusting that instead
           | is a 1000x better option.
        
         | girzel wrote:
         | All of my passwords are in the "pass" command line utility,
         | where they're encrypted with gpg. I added my brother's gpg key
         | as an encryption target, and his ssh key onto the sever where
         | the git repo is stored, locked down to the git shell command.
         | In the event of my untimely demise, my wife tells him the url
         | of the git repo.
        
           | [deleted]
        
       | roastedpeacock wrote:
       | The lack of per-application isolation with desktops is one of
       | those ugly truths people try and sweep under the rug.
       | 
       | I foresee two potential solutions to this.
       | 
       | 1) Run everything in a VM like Qubes (essentially nerfs certain
       | application like 3D acceleration without major R&D)
       | 
       | 2) Utilize some container runtime to provide isolation for legacy
       | applications and stub out features such as filesystem calls so
       | they do not to be aware of its existence.
       | 
       | Microsoft tried to produce a crippled application runtime for
       | Windows (UWP) with more security, but considering its lack of
       | backwards compatibility and lesser feature-set it is not that
       | surprising that adoption has been an uphill battle.
        
         | megous wrote:
         | Per-application isolation sounds completely unworkable for a
         | developer.
         | 
         | Maybe per-customer isolation, or per-usecase isolation.
         | 
         | Isolating customer work (or use case like "production
         | deployment") into separate UNIX user accounts works fairly
         | reasonably.
        
         | mhoad wrote:
         | Fuschia from Google also looks to have a very good solution to
         | this problem but is probably still a couple of years away.
        
           | FabHK wrote:
           | They should really pick a name that's easier to spell...
           | 
           | https://en.wikipedia.org/wiki/Fuchsia_(operating_system)
        
             | mhoad wrote:
             | I should stop posting while drinking wine too it seems :)
        
         | sva_ wrote:
         | FireJail does at least some isolation
        
         | greesil wrote:
         | Does chrome OS do this?
        
           | est31 wrote:
           | Chrome OS has sandboxed developer environments, which is
           | pretty neat: https://www.youtube.com/watch?v=pRlh8LX4kQI
        
         | Ameo wrote:
         | I think that the browser is going to eat the desktop/OS and
         | that most apps will eventually be browser-based.
         | 
         | PWAs are the initial movement in that direction. As browser
         | APIs expand and support more use-cases through WebAssembly,
         | WebGPU, native filesystem APIs, etc. more and more apps that
         | were primarily or only available as native can be supported in
         | the browser.
         | 
         | I know that many people hate web apps because they're often
         | slow, clunky, bloated, etc. but a lot of that is changing as
         | the frontend ecosystem embraces new and more efficient
         | frameworks and technologies. The browser provides everything
         | one needs to build fast and responsive applications - It's an
         | issue with incentives and culture more than anything to do with
         | the fundamental tech.
        
         | slimsag wrote:
         | UWP has also been deprecated[0]
         | 
         | [0] https://www.thurrott.com/dev/258377/microsoft-officially-
         | dep...
        
         | walterbell wrote:
         | Apple will likely launch Armv9 CPUs (iDevice A16 and MacBook
         | M2) this year. If they don't enable CCA and memory tagging,
         | then we have to wait for Armv9 support in QEMU and a future
         | Qualcomm SoC, https://www.anandtech.com/show/16584/arm-
         | announces-armv9-arc...
         | 
         |  _> CCA introduces a new concept of dynamically created
         | "realms", which can be viewed as secured containerised
         | execution environments that are completely opaque to the OS or
         | hypervisor. The hypervisor would still exist, but be solely
         | responsible for scheduling and resource allocation. The realms
         | instead, would be managed by a new entity called the "realm
         | manager", which is supposed to be a new piece of code roughly 1
         | /10th the size of a hypervisor.
         | 
         | > Applications within a realm would be able to "attest" a realm
         | manager in order to determine that it can be trusted, which
         | isn't possible with say a traditional hypervisor. Arm didn't go
         | into more depth of what exactly creates this separation between
         | the realms and the non-secure world of the OS and hypervisors,
         | but it did sound like hardware backed address spaces which
         | cannot interact with each other._
        
           | KMag wrote:
           | That's great! The processor's hypervisor-like firmware should
           | handle task switching, page table manipulation, etc, and the
           | OS kernel should use upcalls to the firmware instead of
           | needing to have various special-case paths for various minor
           | hardware variants. Had the x86 BIOS been a bit better
           | designed (and a bit more performant), we likely would have
           | seen OS kernels leaning much harder on firmware that shipped
           | with the processor instead of having to make as many
           | assumptions about the hardware and special-case checks.
           | 
           | Besides allowing for more easily isolated security domains,
           | this allows things like (if properly designed) not needing to
           | wait for kernel improvements to take advantage of more/wider
           | vector registers or other changes that change the amount of
           | processor state to serialize/deserialize when task switching.
           | 
           | The DEC Alpha AXP worked somewhat like this with its PALCode
           | firmware. The Tru64 UNIX (and Linux, *BSD, etc.) and VMS
           | kernels actually were unable to execute the privileged CPU
           | instructions. The OS kernel needed to make upcalls to the
           | PALCode, which then could use privileged instructions and
           | could see model-specific registers, etc. The PALCode version
           | used for Tru64 emulated two protection rings, and the PALCode
           | version used with VMS emulated more (I think 4) rings of
           | protection by just keeping an extra integer around for each
           | task, and using that to determine which tasks could currently
           | make which upcalls. One could (and probably should) extend
           | this ring emulation to a bit vector of per-task revokable
           | capabilities that could be passed to child
           | tasks/processes/threads.
           | 
           | Hopefully we see something like this for RISC-V, using seL4
           | for the "realm manager". This would probably require an extra
           | userspace driver process running to intermediate realm setup
           | and manipulation, but wouldn't be in the critical path for
           | system calls or other userspace drivers.
           | 
           | We're already running hypervisors so many places that it
           | makes sense to run a formally verified separation kernel
           | everywhere, and run hypervisors and OS kernels as userspace
           | daemons. This avoids the hypervisor needing to emulate
           | hardware as an ad-hoc upcall mechanism and instead simplifies
           | both the hypervisor and the OS kernel. The overhead of modern
           | microkernels is so low that your cell phone's baseband
           | processor is likely running an L4 microkernel. It's called
           | paravirtualization when the OS kernel is modified to use
           | upcalls to the hypervisor instead of trying to perform
           | privileged operations that will be trapped (and then
           | emulated) by the hypervisor. Paravirtualization improves VM
           | performance and potentially sidesteps hypervisor emulation
           | bugs, but it would simplify the kernel (and potentially make
           | it easier to optimize) if OS kernels ran paravirtualized even
           | when there is one guest OS per physical computerp
           | 
           | Edit: Of course, there's a small performance hit in the
           | single guest OS case, but if that's the common code path,
           | presumably both hardware and the kernels could be better
           | optimized. Also, if you're supporting OS-opaque realms,
           | you're already paying this hypervisor cost all the time
           | anyway.
        
       | md_ wrote:
       | Er, I'm confused. Is the point of this essay that endpoints might
       | be compromised?
       | 
       | I mean, yeah? I agree, I guess? But also, that's not an
       | interesting observation, is it?
        
         | cf141q5325 wrote:
         | It runs counter to popular belief. The author makes however a
         | good case for it going the way of "deleting cookies / using
         | VPNs ... anonymizes you" soon. You get a while of "this is only
         | theoretical" till one day its common knowledge.
         | 
         | I blame complexity btw. Burn it all down and we might be able
         | to start over in rather acceptable digital stone age.
        
       | benlivengood wrote:
       | While it's quite likely to have a device I own compromised at
       | some point it's less likely for everything to be compromised at
       | once. My phone can access some backends, my laptop can access
       | some others. Full backups are accessible from either. 2-factor
       | authentication makes compromise of _all_ accounts less likely.
       | 
       | It should be possible, for someone who wants a very low chance of
       | losing all their data, to remember 2 or 3 passphrases and
       | compartmentalize access to servers and backups such that most
       | backups are pull instead of push (or have restricted permission
       | ala 'zfs allow') and compromising everything requires attacking
       | multiple platforms all at once.
       | 
       | Make sure it's possible to access everything starting from fresh
       | installs on fresh hardware; once it's clear that one device has
       | been compromised it's best policy to begin fresh on all devices
       | as soon as possible and then start restoring from backups. Have
       | some offline backups.
       | 
       | To be fair, convenience trumps some of these guidelines. Security
       | is hard and only organizations can achieve a high level of
       | resilience since brain backups don't exist yet.
        
       | tagrun wrote:
       | Sandboxing without any overhead is pretty accessible on any Linux
       | distro, so I don't see why QubesOS should be the go-to choice.
       | For example, I use firejail for all internet facing applications
       | that I use (also for Wine and any proprietary software):
       | https://wiki.archlinux.org/title/firejail#Using_Firejail_by_...
       | The setup takes just a couple of minutes.
        
       | gz5 wrote:
       | Add network isolation to your defense in depth strategy. Close
       | all link listeners and inbound firewall ports. Open authorized-
       | only, outbound-only, ephemeral sessions.
        
         | walterbell wrote:
         | DNS and HTTPS are wide-open ports. Would be nice to have a
         | subscription service that maps popular web services to known-
         | good destination IP address ranges for firewall rules.
         | 
         | Is Suricata a good option for network intrusion detection?
        
           | gz5 wrote:
           | I like that Suricata is open source but haven't used it. You
           | can close all your inbound ports and link listeners, e.g.
           | locally resolved DNS and outbound-only https, only for
           | authorized sessions.
        
       | hsbauauvhabzb wrote:
       | I see a lot of trust in VMs, but jailbreaks exist, in the future
       | I anticipate more spectre/meltdown type vulns, or even physics
       | based attacks like rowhammer. Assuming my threat model was
       | infinite, can I really trust vms?
        
       | jsnell wrote:
       | > If you're not a cyber criminal or don't have a lot of crypto to
       | steal, this will probably never happen to you...
       | 
       | This is a misunderstanding of the threat in two ways.
       | 
       | First, malware is not purely, or even primarily, a targeted
       | threat. It's actually a shockingly easy attack to scale, and by
       | far the most victims are not any kind of high profile target.
       | They are either unsophisticated or careless computer users, who
       | installed something they shouldn't have. And the thing is, from
       | most malware authors' perspective it doesn't matter that much
       | whom they compromise. All victims can be monetised to some
       | extent, and there is an elaborate ecosystem to make sure that
       | monetisation happens in practice, not just in theory.
       | 
       | Second, the list of high value targets is definitely not limited
       | to criminals and cryptocurrency owners. They might be the only
       | people for whom the risk model is specifically the theft of a key
       | file from the local disk.
       | 
       | But you know what else is a file on the local disk? The browser
       | cookie jar, full of bearer tokens granting access to all your
       | online services. Have a short Instagram name? An established but
       | not particularly popular YouTube channel? Do your banking online?
       | Have an account on Steam with some bought games? All of that is
       | worth money to an attacker, and them realising that value will
       | hurt you.
       | 
       | As for what to do about it? Hardware crypto is the technical
       | answer, but it will take ages to move the ecosystem there. Until
       | then, segregate the things whose compromise would be really
       | harmful to separate devices from the day to day, ideally ones
       | that are actively supported and have a good security model (e.g
       | an iPad or Chromebook).
        
         | walterbell wrote:
         | The workstations of software developers and
         | system/network/CI/AD admins are also high value targets for
         | supply chain attacks.
        
       ___________________________________________________________________
       (page generated 2022-04-17 23:00 UTC)