![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to q-security.tex CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDReno / contrib / isode-beta / doc / manual|
Return to q-security.tex CVS log | Up to [CSRG BSD Unix] / 43BSDReno / contrib / isode-beta / doc / manual |
1.1 root 1: % Run this through LaTeX with the appropriate wrapper.
2:
3: \chapter{Introduction to Security Features}
4: \label{Security}
5:
6: \section{Passwords}
7: \label{Passwords}\index{user password attribute}
8:
9: When you bind to a DSA, to get write access you need to tell the DSA who you
10: are --- you do this by supplying your distinguished name.
11: So that the DSA can authenticate you, you also need to supply your Quipu
12: password.
13: Anyone knowing your
14: password can act as you and alter your data. Therefore your password should be well-chosen
15: and kept safe.
16:
17: \subsection{Choosing a Password}
18:
19: \begin{itemize}
20: \item
21: Don't use the same password for QUIPU as you do for login.
22:
23: It is always bad practise (but convenient!) to use the same password on
24: different systems. The manager of your QUIPU DSA can discover your QUIPU
25: password. This doesn't affect the security of QUIPU (as your DSA manager
26: can alter local data anyway),
27: but the QUIPU manager is probably not allowed access to
28: your login account.
29: \item
30: Don't choose an obvious word.
31:
32: Your password should {\bf not} be any of the following:
33: \begin{itemize}
34: \item
35: Your name, initials, date of birth, place of work or similar
36: personal details.
37: \item
38: Any girl's name in any language.
39: \item
40: The name of a film star, television personality etc.
41: \item
42: The name of a character from a science-fiction or fantasy novel.
43: \item
44: Computer jargon e.g. ``foobar''.
45: \item
46: Any of the above, spelt backwards.
47: \item
48: Any word from your system's on-line dictionary. Ideally, your password
49: should not be a word at all (it could be the concatenation of two unrelated
50: words, for example).
51: \end{itemize}
52: \item
53: Change your password from time to time.
54: \end{itemize}
55:
56: \subsection{Taking Care of Your Password}
57:
58: \begin{itemize}
59: \item
60: Configuration Files
61:
62: It is possible to put your QUIPU password in a configuration file in your
63: home directory (see the later chapters on user interfaces).
64: If you do this, you must make sure that the configuration file (.quipurc)
65: is not publicly readable (by using the \unix/ {\em chmod} command, for
66: example).
67: \item
68: Access Control Lists
69:
70: Your QUIPU password is itself stored in QUIPU, as the {\em userPassword}
71: attribute of your entry. You should make sure that the access control list
72: for your entry grants public {\em compare} but not {\em read} access to
73: this attribute. (The attribute must be publicly comparable so that QUIPU
74: can check that have presented the right password when you start a session).
75:
76: The next section will explain how to set up access control lists.
77: \item
78: Don't give your password to other people.
79:
80: If several people need to be able
81: to modify the same data, the access control lists can be set up so that this
82: is possible without them sharing passwords.
83: \item
84: Don't write your password down!
85: \end{itemize}
86:
87: \section{Discretionary Access Control}
88: \label{disc_acl}\index{acl}
89:
90: ``Discretionary Access Control'' is any means by which users can (at their
91: discretion) give other users access to data which they control. In QUIPU,
92: access control lists are used to provide discretionary access control.
93:
94: \subsection{Model}
95:
96: Each node in the DIT held by a QUIPU DSA has a QUIPU access control list (ACL).
97: The ACL is divided into three parts :
98:
99: \begin{enumerate}
100: \item
101: Child ACL
102:
103: This controls who may discover or change which entries are placed immediately
104: below the node in the DIT.
105: \item
106: Entry ACL
107:
108: This controls who may access the entry placed at the node.
109: \item
110: Attribute ACL
111:
112: For every attribute of the entry, there is an Attribute ACL which controls who
113: may access that attribute. To keep the representation compact, each entry has
114: a default Attribute ACL. This is used for all the attributes of the entry that
115: have not been explicitly given a different Attribute ACL.
116: \end{enumerate}
117:
118: Each Entry, Child or Attribute ACL (henceforth called an Object ACL) consists
119: of a list of (access selector, access level) pairs. It associates every
120: Distinguished Name with an access level, according to the following rule:
121:
122: \begin{quote}
123: Take every pair where the selector
124: (left hand side) matches the name; The associated access level is the maximum
125: of the corresponding right hand sides. If no selectors match the name, the
126: associated access level is {\em none}.
127: \end{quote}
128:
129: The levels of access are as follows :
130:
131: \begin{enumerate}
132: \item
133: None
134:
135: No accesses to the object are allowed.
136: \item
137: Detect
138:
139: A DUA can detect that the protected object exists.
140: \item
141: Compare
142:
143: A filter (e.g. test for equality to some value) may be applied to the object.
144: \item
145: Read
146:
147: The contents of the object may be read.
148: \item
149: Add
150:
151: The contents of the object may be added to, but not removed from.
152: \item
153: Write
154:
155: The contents of the object may be modified in any way.
156: \end{enumerate}
157:
158: The possible Access Selectors are as follows :
159:
160: \begin{enumerate}
161: \item
162: Entry
163:
164: Matches the entry itself only.
165: \item
166: Other
167:
168: Matches everything.
169: \item
170: Prefix $<$name$>$
171:
172: Matches $<$name$>$ and everything below it in the DIT.
173: \item
174: Group $<$name$>$
175:
176: Matches $<$name$>$.
177: (This is not what the `group' selector was originally designed for, but it is
178: currently what it does!)
179:
180: \end{enumerate}
181:
182: The attribute syntax used to represent this is defined in Section~\ref{acl_syntax},
183: with the ASN definition shown in Figure~\ref{acl-py}.
184:
185: \tagrind {acl}{ACL definition}{acl-py}
186:
187:
188:
189: \subsection{Detect Access}
190:
191: QUIPU treats the access level {\em none} as though it were {\em detect}.
192: This means that is often possible to detect the presence of protected data,
193: even if you have no access to it.
194:
195: The reason for this is that it is very difficult for the Directory to
196: pretend that data isn't there; carefully chosen queries can catch it out.
197: Access control mechanisms that can be by-passed are very dangerous; they
198: give a false sense of security. Accordingly, we have decided not to
199: implement ``undetectable data''.
200:
201: \subsection{Effect of ACLs on Operations}
202:
203: This section explains which ACLs are checked for each of the X.500 operations.
204:
205: \begin{enumerate}
206: \item
207: List
208:
209: The Child ACL of the target must give at least {\em read} access. In addition,
210: each child will only be listed if its Entry ACL gives at least {\em read}.
211: Later versions of QUIPU may also require that the Attribute ACL of the
212: distinguished (naming) attribute of the child give at least {\em read} access.
213: \item
214: Search
215:
216: To search the immediate descendants of a node, that node's Child ACL must give
217: at least {\em read} access. In addition, each child will only be searched
218: if its Entry ACL gives at least {\em compare} access. The filter `present'
219: may be applied to any attribute. Other basic
220: filters evaluate to {\em maybe} unless the relevant Attribute ACL gives at
221: least compare access.
222: \item
223: Read
224:
225: The Entry ACL of the target must give at least {\em read} access and the
226: Attribute ACL of each attribute read must give at least {\em read} access.
227: \item
228: Compare
229:
230: The Entry ACL of the target must give at least {\em compare} access. The
231: Attribute ACL of the tested attribute must give at least {\em compare}
232: access.
233: \item
234: Modify
235:
236: The Entry ACL of the target must give at least {\em add} access if attributes
237: or values are to be added, and at least {\em write} access if they are to
238: be removed. For each attribute changed, the Attribute ACL must give at
239: least {\em add} access for an attribute or value to be added, and at least
240: {\em write} access for an attribute or value to be removed.
241: \item
242: Add Entry
243:
244: To add an entry below a node, that node's Child ACL must give at least
245: {\em add} access.
246: \item
247: Remove Entry
248:
249: To remove an entry, the Child ACL of its parent must give at least {\em write}
250: access. No rights to the entry itself are required.
251: \item
252: Modify RDN
253:
254: The Child ACL of the target's parent must give at least {\em write} access.
255: If the operation needs to add an attribute (value), the target's Entry ACL must
256: give {\em add} access and the Attribute ACL of the attribute must give
257: {\em add} access.
258: If the operation needs to remove an attribute (value), the target's Entry ACL
259: must give {\em write} access and the Attribute ACL of the attribute must give
260: {\em write} access.
261: \end{enumerate}
262:
263: \subsection {Example Use of ACLs}
264:
265: A node representing a user might be given the following ACL:
266:
267: \begin{itemize}
268: \item
269: ChildACL is not applicable, and so omitted.
270: \item
271: EntryACL is \{other, read\} + \{self, write\} + \{group=$<$Manager Name$>$,
272: write\}, so that only the user or a manager can change the entry.
273: Using the ACL syntax, this is expressed as:
274: \begin{quote}\begin{verbatim}
275: acl= other # read # entry
276: acl= self # write # entry
277: acl= group # <Manager Name> # write # entry
278: \end{verbatim}\end{quote}
279: \item
280: DefaultAttributeACL is \{other, read\} + \{self, write\}, which leads to
281: publicly readable attributes modifyable by the user.
282: Using the ACL syntax, this is expressed as:
283: \begin{quote}\begin{verbatim}
284: acl= other # read # default
285: acl= self # write # default
286: \end{verbatim}\end{quote}
287: \item
288: The Attribute ACL for ACL is \{other, read\} + \{group = $<$Manager Name$>$,
289: write\}, so that only the manager can change the ACL.
290: Using the ACL syntax, this is expressed as:
291: \begin{quote}\small\begin{verbatim}
292: acl= other # read # attributes # acl
293: acl= group # <Manager Name> # write # attributes # acl
294: \end{verbatim}\end{quote}
295: \item
296: The Attribute ACL for Password is \{self, write\} + \{other, compare\} so that
297: the user can change the password, DSA's can check the password, and only
298: the user can read it.
299: \begin{quote}\begin{verbatim}
300: acl= self # write # attributes # userPassword
301: acl= other # compare # attributes # userPassword
302: \end{verbatim}\end{quote}
303: \end{itemize}
304:
305: A node representing an organisation or organisational unit might be given the
306: following ACL:
307:
308: \begin{itemize}
309: \item
310: ChildACL is \{other, read\} + \{group=$<$Manager Name$>$, write\}. Everybody can
311: search the members of the organisation, but only the manager is allowed to add
312: or delete members.
313: This is represented as an attribute with:
314: \begin{quote}\begin{verbatim}
315: acl= other # read # child
316: acl= group # <Manager Name> # write # child
317: \end{verbatim}\end{quote}
318: \item
319: EntryACL is \{other, read\} + \{group=$<$Manager Name$>$, write\}.
320: This is represented as an attribute with:
321: \begin{quote}\begin{verbatim}
322: acl= other # read # entry
323: acl= group # <Manager Name> # write # entry
324: \end{verbatim}\end{quote}
325: \item
326: DefaultAttributeACL is \{other, read\} + \{group=$<$Manager Name$>$, write\}.
327: This is represented as an attribute with:
328: \begin{quote}\begin{verbatim}
329: acl= other # read # default
330: acl= group # <Manager Name> # write # default
331: \end{verbatim}\end{quote}
332: \end{itemize}
333:
334: Every entry in the QUIPU DIT must have an acl attribute.
335: If you do not supply one, the the default is added.
336: The default ACL is often printed as
337: \begin{quote}\begin{verbatim}
338: acl=
339: \end{verbatim}\end{quote}
340: with no value.
341: The default ACL is everybody read everything, but self can write, in long
342: form this is expressed as:
343: \begin{quote}\begin{verbatim}
344: acl= self # write # entry
345: acl= self # write # child
346: acl= self # write # default
347: acl= others # read # entry
348: acl= others # read # child
349: acl= others # read # default
350: \end{verbatim}\end{quote}
351: For many entries this is sufficient.
352:
353: It can be seen that this scheme gives a great deal of flexibility,
354: without the addition of any protocol elements.
355: The encoding is designed so that the volume overhead is not excessive
356: for sensible access policies.
357:
358:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.