begin quoting Lan Barnes as of Sat, Dec 02, 2006 at 04:12:21PM -0800: > On Sat, December 2, 2006 8:26 am, Stewart Stremler wrote: [snip] > > When has a security person ever been able to trust a corporate user? > > > > Sure, they can trust _some_, but they have to set a policy, and the > > policy has to work for _all_ of their users. Including the idiotic > > ones, or the forgetful ones ( who walk away from their terminal ), etc. > > But here's my problem. If the password is in the expect script, then they > have to trust the users to lock up read on the script. And you can't lock up read access on a script, as you have to read a script to execute it, at least on a *nix platform.
> 'Course, Gabe was talking about hacking a little interface to request the > password, but that's happening in user space, subject to swap (hard to see > that happening, but it could), etc. Well, ssh-agent runs in user-space as well, so it's a wash there. Defending swap is do-able, if you feel the risk is signficant enough. > So they're trusting at the least Gabe on expect and maybe their users, too. Well, Gabe putting passwords in an expect script is something that's likely to be caught in an audit, should there be one. So he has incentive to avoid doing such things, which, as we see, is working. Plus, they're not messing about with deleting stuff in user's directories (or we've not been told that they do), which is good; folks who go around destroying other's data don't deserve much respect. I don't recall if Gabe is working in a single-account shop (every machine has a login for you with the same username/password/etc.) or not. If not, then the stated policy sounds like it might slow down a blatant attack... It probably doesn't hurt to have a little slack to allow for supersitition; especially if it's their backside on the hotseat should someone follow their rules, abide by policy, and still be the vector for inadvertent compromise. There are companies that disallow SSH entirely in the name of security. And since it's their network, and they're the ones who'll get in trouble, it's their call. -- _ |\_ \| -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
