⟦b540db569⟧

TextFile

% Run this through LaTeX with the appropriate wrapper.

\chapter{Introduction to Security Features}
\label{Security}

\section{Passwords}
\label{Passwords}\index{user password attribute}

When you bind to a DSA, to get write access you need to tell the DSA who you
are --- you do this by supplying your distinguished name.
So that the DSA can authenticate you, you also need to supply your Quipu
password.
Anyone knowing your
password can act as you and alter your data. Therefore your password should be well-chosen
and kept safe.

\subsection{Choosing a Password}

\begin{itemize}
\item
Don't use the same password for QUIPU as you do for login.

It is always bad practise (but convenient!) to use the same password on
different systems. The manager of your QUIPU DSA can discover your QUIPU
password. This doesn't affect the security of QUIPU (as your DSA manager
can alter local data anyway), 
but the QUIPU manager is probably not allowed access to
your login account.
\item
Don't choose an obvious word.

Your password should {\bf not} be any of the following:
\begin{itemize}
\item
Your name, initials, date of birth, place of work or similar
personal details.
\item
Any girl's name in any language.
\item
The name of a film star, television personality etc.
\item
The name of a character from a science-fiction or fantasy novel.
\item
Computer jargon e.g. ``foobar''.
\item
Any of the above, spelt backwards.
\item
Any word from your system's on-line dictionary. Ideally, your password
should not be a word at all (it could be the concatenation of two unrelated
words, for example).
\end{itemize}
\item
Change your password from time to time.
\end{itemize}

\subsection{Taking Care of Your Password}

\begin{itemize}
\item
Configuration Files

It is possible to put your QUIPU password in a configuration file in your
home directory (see the later chapters on user interfaces).
If you do this, you must make sure that the configuration file (.quipurc)
is not publicly readable (by using the \unix/ {\em chmod} command, for
example).
\item
Access Control Lists

Your QUIPU password is itself stored in QUIPU, as the {\em userPassword}
attribute of your entry. You should make sure that the access control list
for your entry grants public {\em compare} but not {\em read} access to
this attribute. (The attribute must be publicly comparable so that QUIPU
can check that have presented the right password when you start a session).

The next section will explain how to set up access control lists.
\item
Don't give your password to other people.

If several people need to be able
to modify the same data, the access control lists can be set up so that this
is possible without them sharing passwords.
\item
Don't write your password down!
\end{itemize}

\section{Discretionary Access Control}
\label{disc_acl}\index{acl}

``Discretionary Access Control'' is any means by which users can (at their
discretion) give other users access to data which they control. In QUIPU,
access control lists are used to provide discretionary access control.

\subsection{Model}

Each node in the DIT held by a QUIPU DSA has a QUIPU access control list (ACL).
The ACL is divided into three parts :

\begin{enumerate}
\item
Child ACL

This controls who may discover or change which entries are placed immediately
below the node in the DIT.
\item
Entry ACL

This controls who may access the entry placed at the node.
\item
Attribute ACL

For every attribute of the entry, there is an Attribute ACL which controls who 
may access that attribute. To keep the representation compact, each entry has
a default Attribute ACL. This is used for all the attributes of the entry that
have not been explicitly given a different Attribute ACL.
\end{enumerate}

Each Entry, Child or Attribute ACL (henceforth called an Object ACL) consists
of a list of (access selector, access level) pairs. It associates every
Distinguished Name with an access level, according to the following rule:

\begin{quote} 
Take every pair where the selector
(left hand side) matches the name; The associated access level is the maximum 
of the corresponding right hand sides. If no selectors match the name, the
associated access level is {\em none}.
\end{quote}

The levels of access are as follows :

\begin{enumerate}
\item
None

No accesses to the object are allowed.
\item
Detect

A DUA can detect that the protected object exists.
\item
Compare

A filter (e.g. test for equality to some value) may be applied to the object.
\item
Read

The contents of the object may be read.
\item
Add

The contents of the object may be added to, but not removed from.
\item
Write

The contents of the object may be modified in any way.
\end{enumerate}

The possible Access Selectors are as follows :

\begin{enumerate}
\item
Entry

Matches the entry itself only.
\item
Other

Matches everything.
\item
Prefix $<$name$>$

Matches $<$name$>$ and everything below it in the DIT.
\item
Group $<$name$>$

Matches $<$name$>$.
(This is not what the `group' selector was originally designed for, but it is
currently what it does!)

\end{enumerate}

The attribute syntax used to represent this is defined in Section~\ref{acl_syntax}, 
with the ASN definition shown in Figure~\ref{acl-py}.

\tagrind {acl}{ACL definition}{acl-py}



\subsection{Detect Access}

QUIPU treats the access level {\em none} as though it were {\em detect}.
This means that is often possible to detect the presence of protected data,
even if you have no access to it.

The reason for this is that it is very difficult for the Directory to
pretend that data isn't there; carefully chosen queries can catch it out.
Access control mechanisms that can be by-passed are very dangerous; they
give a false sense of security. Accordingly, we have decided not to
implement ``undetectable data''.

\subsection{Effect of ACLs on Operations}

This section explains which ACLs are checked for each of the X.500 operations.

\begin{enumerate}
\item
List

The Child ACL of the target must give at least {\em read} access. In addition,
each child will only be listed if its Entry ACL gives at least {\em read}.
Later versions of QUIPU may also require that the Attribute ACL of the
distinguished (naming) attribute of the child give at least {\em read} access.
\item
Search

To search the immediate descendants of a node, that node's Child ACL must give
at least {\em read} access. In addition, each child will only be searched
if its Entry ACL gives at least {\em compare} access. The filter `present'
may be applied to any attribute. Other basic
filters evaluate to {\em maybe} unless the relevant Attribute ACL gives at
least compare access.
\item
Read

The Entry ACL of the target must give at least {\em read} access and the 
Attribute ACL of each attribute read must give at least {\em read} access.
\item
Compare

The Entry ACL of the target must give at least {\em compare} access. The
Attribute ACL of the tested attribute must give at least {\em compare}
access.
\item
Modify

The Entry ACL of the target must give at least {\em add} access if attributes
or values are to be added, and at least {\em write} access if they are to
be removed. For each attribute changed, the Attribute ACL must give at
least {\em add} access for an attribute or value to be added, and at least
{\em write} access for an attribute or value to be removed.
\item
Add Entry

To add an entry below a node, that node's Child ACL must give at least
{\em add} access.
\item
Remove Entry

To remove an entry, the Child ACL of its parent must give at least {\em write}
access. No rights to the entry itself are required.
\item
Modify RDN

The Child ACL of the target's parent must give at least {\em write} access.
If the operation needs to add an attribute (value), the target's Entry ACL must
give {\em add} access and the Attribute ACL of the attribute must give
{\em add} access.
If the operation needs to remove an attribute (value), the target's Entry ACL 
must give {\em write} access and the Attribute ACL of the attribute must give
{\em write} access.
\end{enumerate}

\subsection {Example Use of ACLs}

A node representing a user might be given the following ACL:

\begin{itemize}
\item
ChildACL is not applicable, and so omitted.
\item
EntryACL is \{other, read\} + \{self, write\} + \{group=$<$Manager Name$>$,
write\}, so that only the user or a manager can change the entry.
Using the ACL syntax, this is expressed as:
\begin{quote}\begin{verbatim}
acl= other # read # entry
acl= self # write # entry
acl= group # <Manager Name> # write # entry
\end{verbatim}\end{quote}
\item
DefaultAttributeACL is \{other, read\} + \{self, write\}, which leads to
publicly readable attributes modifyable by the user.
Using the ACL syntax, this is expressed as:
\begin{quote}\begin{verbatim}
acl= other # read # default
acl= self # write # default
\end{verbatim}\end{quote}
\item
The Attribute ACL for ACL is \{other, read\} + \{group = $<$Manager Name$>$,
write\},  so that only the manager can change the ACL.
Using the ACL syntax, this is expressed as:
\begin{quote}\small\begin{verbatim}
acl= other # read # attributes # acl
acl= group # <Manager Name> # write # attributes # acl
\end{verbatim}\end{quote}
\item
The Attribute ACL for Password is \{self, write\} + \{other, compare\} so that
the user can change the password, DSA's can check the password, and only
the user can read it.
\begin{quote}\begin{verbatim}
acl= self # write # attributes # userPassword
acl= other # compare # attributes # userPassword
\end{verbatim}\end{quote}
\end{itemize}

A node representing an organisation or organisational unit might be given the
following ACL:

\begin{itemize}
\item
ChildACL is \{other, read\} + \{group=$<$Manager Name$>$, write\}. Everybody can
search the members of the organisation, but only the manager is allowed to add
or delete members.
This is represented as an attribute with:
\begin{quote}\begin{verbatim}
acl= other # read # child
acl= group # <Manager Name> # write # child
\end{verbatim}\end{quote}
\item
EntryACL is \{other, read\} + \{group=$<$Manager Name$>$, write\}.
This is represented as an attribute with:
\begin{quote}\begin{verbatim}
acl= other # read # entry
acl= group # <Manager Name> # write # entry
\end{verbatim}\end{quote}
\item
DefaultAttributeACL is \{other, read\} + \{group=$<$Manager Name$>$, write\}.
This is represented as an attribute with:
\begin{quote}\begin{verbatim}
acl= other # read # default
acl= group # <Manager Name> # write # default
\end{verbatim}\end{quote}
\end{itemize}

Every entry in the QUIPU DIT must have an acl attribute.
If you do not supply one, the the default is added.
The default ACL is often printed as
\begin{quote}\begin{verbatim}
acl=
\end{verbatim}\end{quote}
with no value.
The default ACL is everybody read everything, but self can write, in long
form this is expressed as:
\begin{quote}\begin{verbatim}
acl= self # write # entry
acl= self # write # child
acl= self # write # default
acl= others # read # entry
acl= others # read # child
acl= others # read # default
\end{verbatim}\end{quote}
For many entries this is sufficient.  

It can be seen that this scheme gives a great deal of flexibility,
without the addition of any protocol elements.
The encoding is designed so that the volume overhead is not excessive
for sensible access policies.
DataMuseum.dk

DKUUG/EUUG Conference tapes

⟦b540db569⟧ TextFile

Derivation

TextFile
