• ☆ Yσɠƚԋσʂ ☆@lemmy.mlOP
    link
    fedilink
    arrow-up
    5
    ·
    2 years ago

    Disk encryption covers the “dude swiped my laptop” attack vector but not the malicious npm package (or whatever) attack vector.

    There isn’t a perfect security in the face of arbitrary malware, but we have OS key stores for good reason. For example, macOS keychain is encrypted by the SEP, and access to the data requires user authentication on a case by case basis when set correctly. It is not possible for any software at any privilege level to bypass it.

    • kevincox@lemmy.ml
      link
      fedilink
      arrow-up
      1
      ·
      edit-2
      2 years ago

      But the malicious npm package can just read whatever key the app reads then decrypt the values. They are running with the same permission.

      The only thing that really improves this is per-app sandboxing but if you are sandboxing the app then it shouldn’t be able to read any arbitrary files out of your home directly anyways.

      Keychains are an improvement but not much. 99% of users will just unlock the keychain upon login so it doesn’t really provide much benefit. Unsandboxed apps are indistinguishable to the keyring daemon so they can just request one anothers’ keys. (Maybe windows or mac has some codesigning magic so that the keyring daemon knows the identity of the app at a finer grain than the user level? but at this point we are really just back to sandboxed apps).

      Basically there is nearly no point to most apps to doing anything special to store sensitive files. If your app is secure enough that the user will be happy to unlock the keychain on every app launch sure. But that is a nearly non-existent use case. In general the OS should just provide secure storage as the default. For sandboxed apps they won’t have access to each others storage unless explicitly granted, for non-sandboxed apps there isn’t much you can do besides obscurity.

      • ☆ Yσɠƚԋσʂ ☆@lemmy.mlOP
        link
        fedilink
        arrow-up
        1
        ·
        2 years ago

        But the malicious npm package can just read whatever key the app reads then decrypt the values. They are running with the same permission.

        No, it cannot because apps cannot just reach into memory of other apps and keychain access has permissions per application.

          • ☆ Yσɠƚԋσʂ ☆@lemmy.mlOP
            link
            fedilink
            arrow-up
            2
            arrow-down
            1
            ·
            2 years ago

            If set up properly then each application has its own private store that it registers with the keychain. This isn’t exactly rocket science.

            • kevincox@lemmy.ml
              link
              fedilink
              arrow-up
              1
              arrow-down
              2
              ·
              2 years ago

              Do you have links to “set up properly”. The problem is that for most systems other than maybe some of the “app store” type setups the OS has not concept of “application”. The credentials are just the user and that is the same for all unsandboxed apps.

              • ☆ Yσɠƚԋσʂ ☆@lemmy.mlOP
                link
                fedilink
                arrow-up
                2
                ·
                2 years ago

                Here’s an example of controlling access on per application basis with macOS keychain. The basic concept here is that the OS controls access to sensitive data, and applications can have individual stores associated with them. This allows control over what application can access a particular piece of data in the store.

                • kevincox@lemmy.ml
                  link
                  fedilink
                  arrow-up
                  1
                  ·
                  2 years ago

                  That just seems to be about granting an app access to all keys, which is not quite the same as per-app keys.

                  I know that macOS has this for sandboxed apps from the app store, maybe they have it for “sideloaded” apps as well but at least most OSes don’t have that. At least for Windows and Linux there isn’t a good way to identify an “app” to separate it from any other. My macOS knowledge is rusty but IIRC you install apps in a system-owned directory and apps only have permission to update themselves so maybe you could use the application path as a key, but the other listed affected OSes don’t have that.