[wonderfuly]

I'm a victim of this.

In addition to concerns about npm, I'm now hesitant to use the GitHub CLI, which stores a highly privileged OAuth token in plain text in the HOME directory. After the attacker accesses it, they can do almost anything on behalf of me, for example, they turned many of my private repos to public.

[douglascamata]

Apparently, The Github CLI only stores its oauth token in the HOME directory if you don't have a keyring. They also say it may not work on headless systems. See https://github.com/cli/cli/discussions/7109.

For example, in my macOS machines the token is safely stored in the OS keyring (yes, I double checked the file where otherwise it would've been stored as plain text).

[naikrovek]

Yes. KeePassXC is all you need on Linux to have a compatible secret store.

[hombre_fatal]

I use it as my secret store provider but it has its quirks.

It would be better if you could have multiple providers attached (gnome-keyring and keepassxc) and then decide which app uses which provider.

Because only some secrets you want to share across devices, like wifi passwords, and the rest you don’t, like the key chromium uses to encrypt local cookies or the gh cli token.

[kd913]

The defacto install of github CLI on ubuntu systems appears to be snap which is owned by some random dude...

[didntcheck]

That's true, but the same may already be true of your browser's cookie file. I believe Chrome on MacOS and Windows (unsure about Linux) now does use OS features to prevent it being read from other executables, but Firefox doesn't (yet)

But protecting specific directories is just whack-a-mole. The real fix is to properly sandbox code - an access whitelist rather than endlessly updating a patchy blacklist

[naikrovek]

Plan9 had per-process namespaces in 1995.

One could easily allow or restrict visibility of almost anything to any program. There were/are some definite usability concerns with how it is done today (the OS was not designed to be friendly, but to try new things) and those could easily be solved. The core of this existed in the Plan9 kernel and the Plan9 kernel is small enough to be understood by one person.

I’m kinda angry that other operating systems don’t do this today. How much malware would be stopped in its tracks and made impotent if every program launched was inherently and natively walled off from everything else by default?

[brendyn]

I think this normalises running untrustworthy, abusive proprietary software, because they can at least be somewhat contained. The only reason I have apps like Facebook on my android phone is that I have sufficient trust in GrapheneOSs permissions. Then, apps like syncthing become crippled as filesystem virtualisation and restrictions prevent access and modification of files regardless of my consent.

Not disagreeing with the need for isolation though, I just think it should be designed carefully in a zero-sacrifice way (of use control/pragmatic software freedom)

[GrantMoyer]

Linux supports per-process namespaces too, and has tools like firejail to use them for sandboxing, but nonetheless sandboxing is not widely used.

[mcny]

> But protecting specific directories is just whack-a-mole. The real fix is to properly sandbox code - an access whitelist rather than blacklist

I believe Wayland (don't quote me on this because I know exactly zero technical details) as opposed to x is a big step in this direction. Correct me if I am wrong but I believe this effort alone has been ongoing for a decade. A proper sandbox will take longer and risks being coopted by corporate drones trying to take away our right to use our computers as we see fit.

[rkangel]

Wayland is a significant improvement in one specific area (and it's not this one).

All programs in X were trusted and had access to the same drawing space. This meant that one program could see what another one was drawing. Effectively this meant that any compromised program could see your whole screen if you were using X.

Wayland has a different architecture where programs only have access to the resources to draw their own stuff, and then a separate compositor joins all the results together.

Wayland does nothing about the REST of the application permission model - ability to access files, send network requests etc. For that you need more sandboxing e.g. Flatpak, Containers, VMs

[akshitgaur2005]

Maybe I am missing something but how and why would a display protocol have anything to do with file access model??

[Hendrikto]

In Wayland you have these xdg-portals that broker access to the filesystem, microphone, webcam, etc. I am not knowledgeable about the security model though.

[ElectricalUnion]

Portals are used to integrate applications to the host if they're being run inside a sandboxed environment.

They are hooks that latch on the common GUI application library calls for things such as "open file dialogs" such that exeptions to the sandbox are implicitly added as-you-go.

They cannot prevent for example direct filesystem access if the application has permission to open() stuff, like if they're not running in a sandbox, or if said sandbox have a "can see and modify entire filesystem" exception (very common on your average flatpak app, btw).

[internet_points]

portals are used by wayland, but you can also use them without wayland.

E.g. under X you can use bubblewrap or firejail to restrict access to the web or whatever for some program, but still give that program access to for example an xdg portal that lets you "open url in web browser" (except the locked-down program can't for example see the result of downloading that web page)

[febusravenga]

this, this, this

All our tokens should be in is protected keychain and there are no proper cross-platform solutions for this. All gclouds, was aww sdks, gh and other tools just store them in dotfile.

And worst thing, afaik there is no way do do it correctly in MacOS for example. I'd like to be corrected though.

[mcny]

What is a proper solution for this? I don't imagine gpg can help if you encrypt it but decrypt it when you login to gnome, right? However, it would be too much of a hassle to have to authenticate each time you need a token. I imagine macOS people have access to the secure enclave using touch ID but then even that is not available on all devices.

I feel like we are barking up the wrong tree here. The plain text token thing can't be fixed. We have to protect our computers from malware to begin with. Maybe Microsoft was right to use secure admin workstations (saw) for privileged access but then again it is too much of a hassle.

[sakisv]

The way I solve the plain text problem is through a combination of direnv[1] and pass[2].

For a given project, I have a `./creds` directory which is managed with pass and it contains all the access tokens and api keys that are relevant for that project, one per file, for example, `./creds/cloudflare/api_token`. Pass encrypts all these files via gpg, for which I use a key stored on a Yubikey.

Next to the `./creds` directory, I have an `.envrc` which includes some lines that read the encrypted files and store their values in environment variables, like so: `export CLOUDFLARE_API_TOKEN=$(pass creds/cloudflare/api_token)`.

Every time that I `cd` into that project's directory, direnv reads and executes that file (just once) and all these are stored as environment variables, but only for that terminal/session.

This solves the problem of plain-text files, but of course the values remain in ENV and something malicious could look for some well known variable names to extract from there. Personally I try to install things in a new termux tab every time which is less than ideal.

I'd like to see if and how other people solve this problem

[1]: https://direnv.net/ [2]: https://www.passwordstore.org/

[gerardnico]

You can even go further and delete all your secrets from your env by creating wrapper scripts

Example : https://github.com/combostrap/devfiles/blob/main/dev-scripts...

It’s not completely full proof but at least gpg asks my passphrase only when I run the script

[hrimfaxi]

At least with direnv your exports are removed when you leave the directory.

[internet_points]

but if you `cd project && npm install compromised-package` then compromised-package's setup script can still read your env vars, right?

[tinodb]

Yes, but I guess that is still much better than that it can read all your .env files on your machine

[L-four]

I think the correct solution is to use a keyring. On Linux there's gnome keyring and last time I worked on a IOS app there was something similar.

This does mean entering your keyring password a lot.

https://en.wikipedia.org/wiki/GNOME_Keyring

[1718627440]

> This does mean entering your keyring password a lot.

Not when you put that keyrings password into the user keyring. I think it is also cached by default.

[masfuerte]

Then what stops the malware accessing the keyring?

[1718627440]

The security boundary on the OS is the user of the process. If you run the malware under the same user as the key, than yes of course it has access. But in production you don't run software under the same user, and on the developer machine you wouldn't put the production key in the user keychain.

[mxey]

On disk, it’s encrypted. The running service, at least on macOS, only hands the item out to specific apps, based on their code signing identity.

[flir]

It might be possible to lash up a cross-plaform solution with KeePassXC. It's got an API that can be accessed from the command line (chezmoi uses it to add secrets to dotfiles). Yes, you'd be authenticating every time you need a token but that might not be too much of a burden if you spend most of your time on a machine with a fingerprint scanner.

otoh I wouldn't do it, because I don't believe I could implement it securely.

[data-ottawa]

I’ve got this work 1password setup, the only issue is if you have background tasks.

I had a Borg backup script for example and 1password needed me to authenticate to run it.

Authenticating for ssh and git is great.

[__turbobrew__]

Yubikey/TouchID

[mxey]

> And worst thing, afaik there is no way do do it correctly in MacOS for example. I'd like to be corrected though.

https://developer.apple.com/documentation/security/keychain-...

And similar services exist on Linux desktops. There are libraries that will automatically pick the right backend.

[akdev1l]

For what it’s worth, the recommended way of getting credentials for AWS would be either:

1. Piggyback of your existing auth infra (eg: ActiveDirectory or whatever you already have going on for user auth) 2. Failing that use identity center to create user auth in AWS itself

Either way means that your machine gets temporary credentials only

Alternatively, we could write an AWS CLI helper to store the stuff into the keychain (maybe someone has)

Not to take away from your more general point

We need flatpak for CLI tools

[queenkjuul]

Snap works with CLI tools. But underneath that, isn't it AppArmor and namespaces? (I don't really know. I'm getting the impression flatpak-style process isolation is possible just not widely adopted)

[1718627440]

This doesn't sound like a technical problem to me. Even my throw-away bash scripts call to `secret-tool lookup`, since that is actually easier than implementing your own configuration.

Also this is a complete non-issue on Unix(-like) systems, because everything is designed around passing small strings between programs. Getting a secret from another program is the same amount of code, as reading it from a text file, since everything is a file.

[naikrovek]

> no way do do it correctly in MacOS

What? The MacOS Keychain is designed exactly for this. Every application that wants to access a given keychain entry triggers a prompt from the OS and you must enter your password to grant access.

[sierra1011]

I'm also a victim of this. Last time I try and install Backstage.

Have you wiped your laptop/infected machine? If not I would recommend it; part of it created a ~/.dev-env directory which turned my laptop into a GitHub runner, allowing for remote code execution.

I have a read-only filesystem OS (Bluefin Linux) and I don't know quite how much this has saved me, because so much of the attack happens in the home directory.