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.gibson_at_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/
Received on 2014-07-04 01:23:45 CEST