Ben wrote: > Rewriting the array isn't seen by the kernel. At least when I initially wrote > that example I tried just setting argv[++i] = "<redacted>" and the ps output > didn't change.
Could that be because of the libtool svn-lt script that sits in the middle? Because in gdb it does change, but not in ps. G On Fri, Jul 4, 2014 at 12:17 AM, Gabriela Gibson <gabriela.gib...@gmail.com> wrote: > This discussion kicked off on the wrong list, so since I started > it, I've concatenated the posts. > > Intro: > ------ > > I used the --password option in a commit and then found that the > process with my password in full view hung around for an entire week > and could be seen by anyone with access to the same machine by using > ps ef. (no passwords were divulged in the process, but some blushes > occurred) > > So, the questions I had were: > > * can and should we make svn's --password option a little more secure > against clumsy users than it currently is? > > * Is there anything we could do to let svn admins compel users to not > use --password? > > * What do we gain by not removing the option of having > passwords in the clear? > > Ben suggested that we maybe should add a sentence warning users that > the --password switch is not secure, since I felt that the current > info about it makes it look too 'legit'. ie.: > > "(this usually is not secure)" > > ----------------------------------------------------- > Julian Foad wrote: > > Gabriela does make some good points. I think it *is* a good idea to > annotate the --password option as Ben suggested, as the first and > simplest response, but we should *also* consider doing more. Merely > providing an option prominently is implicitly promoting it. We should > reconsider how we expose and document it, and even whether we should > still be providing this option at all -- do we know of better best > practices now? > > ------------------------------------------------------ > > This is a summary of Ben's reply: > > Ben Reser wrote on Thu, Jul 03, 2014 at 12:54:58 -0700: > > There are only two options to resolve this in my opinion (ignoring the > simple > > documentation solution): > > > 1) Remove the option. > > > I don't think this is particularly desirable. We use it in our test > suite in > > order to test without having to drive the password prompting.I've used > it in > > examples when showing people how to setup authentication when I wanted > which > > user I was using to always be explicit but didn't want to type a > password all > > the time. Other people are surely using it for automation in places > where they > > aren't concerned about the password leaking via the command line and > it's more > > convenient than seeding the auth cache or driving the password prompts > with > > something like expect. Removing the option certainly creates problems > for us > > as a project with testing and almost certainly causes problems for our > users. > > > 2) Redact the password in the argv after starting up and finding the > bits to > > redact. > > > I have mixed feelings on this one. I'm not entirely sure that all > kernels > > respect this, I know it works on Linux and OS X. But even if we presume > that > > it works on every system where this is an issue, then all it really does > is > > narrow the window in which the password is exposed.If a user is > routinely > > using svn with --password and someone sees the redacted password all > they have > > to do is search for newly made svn processes and race our command line > parser > > to retrieve the password before it gets redacted. So in the end we add > some > > more complexity to our command line tools and users are slightly safer > but > > they're still not really safe. On one hand this helps users in > situations > > where they are not actively being attacked but the password is just > > accidentally observed by someone. But it does nothing to help users who > are > > being actively attacked trying to recover their password.In fact I'd say > it > > creates a false perception of security because the risk would be > obscured from > > the user. > > --------------------------------------- > > Danielsh wrote: > > Ben Reser wrote on Thu, Jul 03, 2014 at 12:54:58 -0700: > > 2) Redact the password in the argv after starting up and finding the > bits to > > redact. > > > > I have mixed feelings on this one. I'm not entirely sure that all > kernels > > respect this, I know it works on Linux and OS X. But even if we presume > that > > it works on every system where this is an issue, then all it really does > is > > It doesn't need to work on "every" system.It just needs to work on > _some_ systems; it'd be fine for it to be a noop on other systems. > > > narrow the window in which the password is exposed. If a user is > routinely > > using svn with --password and someone sees the redacted password all > they have > > to do is search for newly made svn processes and race our command line > parser > > to retrieve the password before it gets redacted. So in the end we add > some > > more complexity to our command line tools and users are slightly safer > but > > they're still not really safe. On one hand this helps users in > situations > > where they are not actively being attacked but the password is just > > accidentally observed by someone. But it does nothing to help users who > are > > being actively attacked trying to recover their password. In fact I'd > say it > > creates a false perception of security because the risk would be > obscured from > > the user. > > Note there is a middle way here: we could partially redact the password, > e.g., replace `password` by `password[:3]` or by > `random.choice(password)`). > > I'm not sure whether it's a good idea (your point about a false > perception of security by uneducated users remains applicable), > > ----------------------------------------- > > Ben wrote in his answer to daniesh: > > On 7/3/14 3:09 PM, Daniel Shahaf wrote: > > Note there is a middle way here: we could partially redact the password, > > e.g., replace `password` by `password[:3]` or by > `random.choice(password)`). > > Right, I realized there are all sorts of things we can do with respect to > redacting the password to deal with the length issue. Like I mentioned > what I > posted was a very simplistic implementation. Another alternative would be > to > simply set all the bytes in the string to '\0' for both the '--password' > argument and the password itself. Thus effectively removing it from the > output, though I suspect that would leave telling extra spaces in the ps > output. > > -------------------------------------------- > Danielsh wrote in reply: > > > Ben wrote: > > Right, I realized there are all sorts of things we can do with respect to > > redacting the password to deal with the length issue. Like I mentioned > what I > > posted was a very simplistic implementation. Another alternative would > be to > > simply set all the bytes in the string to '\0' for both the '--password' > > argument and the password itself. Thus effectively removing it from the > > output, though I suspect that would leave telling extra spaces in the ps > output. > > > > In other words, we'd leak "the user passed the pw via argv" rather than > leak the password itself. We might be able to avoid even that if we > changed the contents of the argv array (e.g., "argv[4] = argv[5]; > argv[5] = NULL"). > > ************************************** > > To which Ben replied: > > On 7/3/14 3:30 PM, Daniel Shahaf wrote: > > In other words, we'd leak "the user passed the pw via argv" rather than > > leak the password itself. We might be able to avoid even that if we > > changed the contents of the argv array (e.g., "argv[4] = argv[5]; > > argv[5] = NULL"). > > Rewriting the array isn't seen by the kernel. At least when I initially > wrote > that example I tried just setting argv[++i] = "<redacted>" and the ps > output > didn't change. > > > -- Visit my Coding Diary: http://gabriela-gibson.blogspot.com/
