DataMuseum.dk

Presents historical artifacts from the history of:

DKUUG/EUUG Conference tapes

This is an automatic "excavation" of a thematic subset of
artifacts from Datamuseum.dk's BitArchive.

See our Wiki for more about DKUUG/EUUG Conference tapes

Excavated with: AutoArchaeologist - Free & Open Source Software.


top - metrics - download
Index: T g

⟦bd5449273⟧ TextFile

    Length: 1372 (0x55c)
    Types: TextFile
    Names: »guest-accounts.tex«

Derivation

└─⟦4f9d7c866⟧ Bits:30007245 EUUGD6: Sikkerheds distributionen
    └─⟦36857feb3⟧ »./papers/Security_Primer/primer.tar.Z« 
        └─⟦5c5f5f2d8⟧ 
            └─⟦this⟧ »guest-accounts.tex« 

TextFile

\section{Guest Accounts}


The computer center guest policy is among the most hotly debated
topics at many computer centers.  From a security standpoint, it
should be obvious that an attacker who has access to a guest account
can break into a computer facility more easily.


\subsection{Attack Difficulty Ratios}

Basically it is a factor of ten easier to break into a machine where
you can easily get as far as a login prompt that one where you can't.
Being able to reach the machine through a standard networking
discipline and open connections to the daemons is worth another order
of magnitude.  Access to a machine that is run by the same group is
worth another factor of three and access to a machine on the same LAN
would grant a factor of three beyond that.  Having a guest account on
the target machine makes the attack still another order of magnitude
easier.  

Essentially, having a guest account on the target simplifies an attack
at least a thousand fold from having to start cold.

\subsection{Individual Sponsors}

I strongly suggest requiring each guest to have an individual staff
sponsor who takes responsibility for the actions of his guest.  

\subsection{The No Guest Policy}

In centers that prohibit guests, staff members often share their
passwords with their guests.  Since these are generally privileged
accounts, this is a significant danger.