Perhaps, but assuming you use the pasteboard feature, this appears to have the same weaknesses as Keychain, and then some. Two come immediately to mind:
I. OS X Screen Sharing, Microsoft's Remote Desktop Connection, and many other remote access clients enable pasteboard sharing with remote hosts by default.
II. Less importantly, any well-known executable taking account identifying information on the command line and storing the account's password in the pasteboard gives local root users an easy way to obtain passwords upon use, with only public, documented APIs:
1. Set dtrace probes on syscall::exec*:entry to fire whenever pass runs.
2. For each such run, save the arguments to pass (obtained in dtrace with copyinstr) and the pasteboard's contents[1], then poll the pasteboard for the next few seconds, and if it changes, save the new contents as well. Depending on the timing, I assume one or the other will be the password for the account described by the arguments to pass.
Finally, I'm not sure what the problem with Keychain here is supposed to be in the first place: after clicking "deny" about 1,000 times, the only passwords the suggested command
revealed on my systems were the blank ones, and my login keychain is not "locked". So I guess this means blank AFP and SMB passwords shouldn't be relied upon to provide meaningful security?
[1] To access the pasteboard server, your "snooping agent" must run in the target user session's Mach bootstrap namespace. Running as root, this is easy:
should do the trick, where PID is the UNIX process ID of the appropriate loginwindow process (under normal circumstances this will be the only loginwindow with the target's EUID).
> I. OS X Screen Sharing, Microsoft's Remote Desktop Connection, and many other remote access clients enable pasteboard sharing with remote hosts by default.
Don't use -c then. Inherent weakness of clipboard.
> II. While I wouldn't personally consider it a "real" security problem, any well-known executable taking account identifying information on the command line and storing the account's password in the pasteboard gives local root users an easy way to obtain passwords upon use, with only public, documented APIs:
This is ridiculous. Of course, if someone has root access they can do whatever they want.
Your technical comments are a bit overblown. If you're root, just replace the executable with a program that pilfers off the passwords. Easy as pie. But sure, you can also dtrace, or load a kernel module, or ... anything?
Not to mention, if you're root, you can just listen to keystrokes, or monitor browser logins, or sniff input fields, or take memory dumps of the whole system, or ... um... anything?
No FUD intended. Given the option, when the alternative is manual entry, many people will use the pasteboard, security be damned. In other words, convenience can be an important part of security.
As for root, while I completely agree, I guess I just prefer concrete examples. Even when running as root, one can never do "anything" for free, and costs are always important to security. Writing a dtrace script is much easier than reverse engineering...well, pretty much anything.
But I'm honestly more interested in how you feel your solution improves upon Keychain's security.
I. OS X Screen Sharing, Microsoft's Remote Desktop Connection, and many other remote access clients enable pasteboard sharing with remote hosts by default.
II. Less importantly, any well-known executable taking account identifying information on the command line and storing the account's password in the pasteboard gives local root users an easy way to obtain passwords upon use, with only public, documented APIs:
1. Set dtrace probes on syscall::exec*:entry to fire whenever pass runs.
2. For each such run, save the arguments to pass (obtained in dtrace with copyinstr) and the pasteboard's contents[1], then poll the pasteboard for the next few seconds, and if it changes, save the new contents as well. Depending on the timing, I assume one or the other will be the password for the account described by the arguments to pass.
Finally, I'm not sure what the problem with Keychain here is supposed to be in the first place: after clicking "deny" about 1,000 times, the only passwords the suggested command
revealed on my systems were the blank ones, and my login keychain is not "locked". So I guess this means blank AFP and SMB passwords shouldn't be relied upon to provide meaningful security?[1] To access the pasteboard server, your "snooping agent" must run in the target user session's Mach bootstrap namespace. Running as root, this is easy:
should do the trick, where PID is the UNIX process ID of the appropriate loginwindow process (under normal circumstances this will be the only loginwindow with the target's EUID).