Live data from Hacker News

Clever uses of pass, the Unix password manager

vitalyparnas.com

21–30 of 154 posts

Re: Clever uses of pass, the Unix password manager

#21

Earlier quoted context omitted.

Are you referring to Pass? There is... https://mssun.github.io/passforios/ Works wonderfully and with OTPauth also. Run a bare git repo on your own network and there is no reason to use Bitwarden. Edit - and for those that are in AWS, you can use pass along with aws-vault to keep your ~/.aws creds in check. https://github.com/99designs/aws-vault

Is there an equivalent for Android?

https://github.com/zeapo/Android-Password-Store#readme

Re: Clever uses of pass, the Unix password manager

#22

Earlier quoted context omitted.

Are you referring to Pass? There is... https://mssun.github.io/passforios/ Works wonderfully and with OTPauth also. Run a bare git repo on your own network and there is no reason to use Bitwarden. Edit - and for those that are in AWS, you can use pass along with aws-vault to keep your ~/.aws creds in check. https://github.com/99designs/aws-vault

Is there an equivalent for Android?

passwordstore, in f-droid: https://f-droid.org/en/packages/dev.msfjarvis.aps/

Re: Clever uses of pass, the Unix password manager

#23
post #7

Earlier quoted context omitted.

And this matters a lot because history is normally only accessible to the current user (and root), but process command line arguments are normally accessible to all users.

I've long thought that was a general problem. Why should I see the command line arguments from other users' processes? What if non-root could see their own processes in detail, but only the program name for other users' processes? Would that break a lot of other things?

Just try to change it by yourself: https://www.cyberciti.biz/faq/linux-hide-processes-from-othe...

sudo mount -o remount,hidepid=1 /proc

Re: Clever uses of pass, the Unix password manager

#24
post #7

Earlier quoted context omitted.

And this matters a lot because history is normally only accessible to the current user (and root), but process command line arguments are normally accessible to all users.

I've long thought that was a general problem. Why should I see the command line arguments from other users' processes? What if non-root could see their own processes in detail, but only the program name for other users' processes? Would that break a lot of other things?

> What if non-root could see their own processes in detail, but only the program name for other users' processes?

At which point you might as well ask why do you need to see other users processes at all? And indeed, that is an option in grsec. I don't think it causes any major breakage, but there are probably some xkcd #1172 sort of things that break.

edit: apparently there is nowdays also options in mainline for that too: https://pipo.blog/articles/20130930-hidepid-process-hiding and also possibly with selinux?

Re: Clever uses of pass, the Unix password manager

#26
post #7

Earlier quoted context omitted.

And this matters a lot because history is normally only accessible to the current user (and root), but process command line arguments are normally accessible to all users.

I've long thought that was a general problem. Why should I see the command line arguments from other users' processes? What if non-root could see their own processes in detail, but only the program name for other users' processes? Would that break a lot of other things?

Hi, great question. Have not seen it being enabled break anything so far (only some cross user invouse written process monitoring scripts). Linux has a flag for this for the /proc mountpoint: hidepid=2

Re: Clever uses of pass, the Unix password manager

#27
post #7

Earlier quoted context omitted.

And this matters a lot because history is normally only accessible to the current user (and root), but process command line arguments are normally accessible to all users.

I've long thought that was a general problem. Why should I see the command line arguments from other users' processes? What if non-root could see their own processes in detail, but only the program name for other users' processes? Would that break a lot of other things?

[deleted]

Re: Clever uses of pass, the Unix password manager

#28
post #7

Earlier quoted context omitted.

And this matters a lot because history is normally only accessible to the current user (and root), but process command line arguments are normally accessible to all users.

I've long thought that was a general problem. Why should I see the command line arguments from other users' processes? What if non-root could see their own processes in detail, but only the program name for other users' processes? Would that break a lot of other things?

Take a look at the `hidepid` option which is available to the /proc filesystem these days:

https://www.cyberciti.biz/faq/linux-hide-processes-from-othe...

Biggest surprise is that people can't run top/ps to see where load is coming from, but that aside I never noticed any particular downsides.

Re: Clever uses of pass, the Unix password manager

#29
post #7

Earlier quoted context omitted.

And this matters a lot because history is normally only accessible to the current user (and root), but process command line arguments are normally accessible to all users.

I've long thought that was a general problem. Why should I see the command line arguments from other users' processes? What if non-root could see their own processes in detail, but only the program name for other users' processes? Would that break a lot of other things?

You can do this by mounting procfs with the hidepid= option. But it breaks systemd when enabled system-wide: https://github.com/systemd/systemd/issues/12955

Individual units can opt-in to this behaviour with the ProtectProc= option though. But I don't think there's currently a good way to apply it to users' interactive processes.

Re: Clever uses of pass, the Unix password manager

#30

I use pass along with passff and my yubikey for gpg decryption of the password store and gpg-ssh syncing from my home git pass db. Works great

passff and other tools like them scare me too much. That browser extension has too much power. All it would take is the author to sell it to some bad actors (or turn into one) and a lot of people will be having a very bad day.

Pasting my password into a form isn't that bad, and it feels far safer.

Post reply on HN