Daniel Danger Bentley wrote:
>
>
> Some files need to be checked out from SVN with root permissions, but
> with user/password of the person who is root at that very moment.
> While
> several people share access to the root accounts, nobody should be
> able
> to check in changes under the name of a different person (or be
> able to
> read the password from the file system).
>
>
> I don't know much about subversion (just joined), but this caught my
> eye: Why are multiple people sharing an account? If you don't trust
> your users, then why do you trust them to share an account?
Pretty good point, I'm glad to see someone thinking about and verifying
my arguments.
Let me explain this with an example:
My concerns are about computing centers with higher security
requirements than normal, partly required by contracts, partly required
by law. So this is not just about "trusting users", this is about
fulfilling external security requirements.
One of these requirements is that certain files are to be protected and
must be accessible to identified and authenticated individuals only,
that's why SVN access is used over HTTPS and with password protection.
Another requirement is that passwords must not be stored in plaintext.
Usually, people do not share accounts and have their own one. But there
are some special cases where this can't be avoided.
E.g. there are server machines that are maintained by a team of system
administrators. Obviously, every one of them must have access to the
root account to install software etc. So when working as administrators,
each of them could become root.
The configuration details (i.e. several files under /etc) must be kept
in a repository with version control, history, change management and
access logging. Subversion perfectly does that job. So several files
under /etc are under subversion control.
Obviously, they should not be checked in or out as root, but as the
admin who is currently doing the job. Therefore, every admin has to
check in and out with his personal login name and passwords. Works
exactly as expected. Being root while accessing the SVN as John or Jane
Doe.
But if the passwords are stored unintentionally under /root, the next
admin could accidently use or read that password.
Another problem: If the admins or regular users write their own
passwords onto the harddisk, they would be written onto backup tapes as
well. Whoever gets access to one of these backup tapes would get the
passwords for free.
Same if an attacker managed to enter a machine: Find the passwords and
break into every other machine (although I agree that he could achieve
the same with modifying the login or svn binaries to store the passwords
somewhere else, but there's no need to make it that easy.)
Reality showed that even if you are fully aware of the problem, there's
always a machine where the config file is as it was delivered by the
linux package.
But this all boils down to a simple rule at the end of the day:
It is a really bad idea to write passwords in plaintext and without
protection into files.
And the discussion so far about trust, passwords on the wire, and so on
showed that the design is based on odd assumptions that do not hold in
common.
regards
Hadmut
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-03-21 18:31:45 CET