[ale] Security best practice - Remove or disable user accounts?

[Michael B. Trausch]

On Thu, 2008-08-07 at 12:32 -0400, Jeff Lightner wrote:
> At a former job the policy was to disable rather than remove user
> accounts.
> 
> However, on checking for “best practices” I don’t find any indication
> why this should be and find several references to removing them
> completely.
> 
> Does anyone know of a best practice that explains why disabling would
> be preferable to removing?

Long story short, I think that removing accounts is something that
should be done later, and disabling sooner, at least for most types of
systems.  More on that below.  I don't think that there is any "best
practice" that I am aware of that concretely explains one over the
other, but given that both types of accounts are equivalent in terms of
having access to the system (neither one can be directly logged into in
a properly functioning system), I think that there can be many arguments
for going in either direction.

The single best reason that I can think of to disable accounts is to
maintain history and consistency in things like log files and records.
Eventually, they can be purged.  This is probably more for application
software and the like, though, as opposed to operating systems, but it
could really apply to either, in many circumstances.

Take, for example, an application that someone uses to fill out trouble
tickets all day long.  User accounts are created on them, tickets are
filled out, and those tickets are linked to the person that created them
by reference.  Referencing data is faster and smaller than duplicating
it, so it makes sense.  When that person leaves, do you delete their
account and then deal with all the orphaned tickets?  You could, but
you're going to lose some history that way.  The log files probably
contain a user ID or login name, and the history should, as well.  The
comments left on the ticket by that user will be the same way.

One of the better ways to handle it is to disable the user account such
that it cannot be logged in or activated through some application or
operating-system sanctioned sudo-like mechanism (or, in the case of the
lack of the latter, that it becomes an automatically-triggered red flag
if something is done with the user account).  Then, once all the records
that the person had anything to do with are moved to archives, the user
account can be expunged from the production system and live on only in
the archives.  The upside to this process is that a simple utility to
check the database consistency and answer questions like, "What if user
X were removed from the system" will be able to tell if you'd
inadvertently create some inconsistency in the database if the user
account were removed.  You can do things like that on the operating
system, too, see if there are any files outside of their ${HOME} that
they owned before getting rid of their user accounts entirely.

The other upshot of doing it this way is that you can't then have
another user come around that has the same username as the old user did,
until that old username is no longer relevant in the system.  Once
everything has been moved off to the archives that pertained to the old
user, a new user with that same name can be created, and there will be
little to no confusion surrounding the identity of the account and its
relation to certain records, because those records won't be in the
production system to cause the confusion to begin with.  You could
potentially get around this by having a historic username list, but that
just duplicates information unnecessarily given that the historic
usernames and their identities will be resolvable in the archives,
simply due to the fact that any time the username is referenced, the
user account information stored in the database snapshot will be valid.

If you use some sort of rotating system that ensures that there is zero
deletion of data, you may have to come up with something slightly more
complex, and it's possible that deletion of user accounts would be
increasingly difficult, leaving the only option to be to archive them as
well and just have them disabled for any type of usage, maybe purging
only data that is older than a certain threshold (like 10 years) when it
no longer has dependencies on it from any data that may be fresher than
that.

From a best-practices point of view, a disabled account and a
non-existent account are both impossible to log into directly.  Assuming
that the implementation of the software is correct in that it never
permits a disabled account to be directly logged into, it won't be an
attack vector of any sort.  Assuming that you can "sudo" into the
account, it'll only be an attack vector that will be used if someone
gains access to the system anyway, and any activity on disabled accounts
that can be accessed in this way should be immediately flagged in some
way by a (presumably external) monitoring system of some sort.  At any
rate, if you've something set-up that enables users to switch identities
in the system with some utility like sudo, then they could just do
something like replace the sudo binary with a binary that lets you
assume the identity of even a non-existent user.  All that'd really need
to be done is for sudo to change process ownership to that user ID
number, and all that's necessary for that to happen is for the check for
an entry in /etc/passwd to not fail and instead return dummy data that
would be looked up in /etc/passwd, though I haven't looked at the
sources to see how (non?)trivial that would be.

	--- Mike

-- 
My sigfile ran away and is on hiatus.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://mail.ale.org/pipermail/ale/attachments/20080807/99304b56/attachment.bin