summaryrefslogtreecommitdiffstats
path: root/sys/contrib/lomac/lomac.h
blob: b16941ab9fcd1bc80d20a116c1b9f6033d127669 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
/*-
 * Copyright (c) 2001 Networks Associates Technology, Inc.
 * All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the above copyright
 *    notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in the
 *    documentation and/or other materials provided with the distribution.
 *
 * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
 * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
 * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
 * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
 * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
 * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 * SUCH DAMAGE.
 *
 * $Id: lomacfs.h,v 1.20 2001/10/17 15:34:29 bfeldman Exp $
 */

#ifndef _LOMAC_H_
#define _LOMAC_H_

/*
 * This file defines the `lattr_t' type, which represents
 * the architecture-independent notion of LOMAC attributes.
 *
 * Each architecture must associate LOMAC attributes with subjects and
 * objects.  This association can be implemented in an architecture-
 * specific way.  However, when it comes time to make a decision by
 * comparing two LOMAC attributes, the architecture-specific code should
 * construct two instances of the architecture-independent lattr_t type
 * and compare them using the lomac_must_demote() and lomac_must_deny()
 * functions.
 *
 * The following two examples demonstrate how architecture-specific code 
 * might do this construction and comparison:
 *
 * EXAMPLE USAGE:
 * 
 * Example 1:  subject x reads object y.
 * (1)  a = LOMAC attributes of subject x
 * (2)  b = LOMAC attributes of object y
 * (3)  demote_result = lomac_must_demote( a, b );
 * (4)  IF demote_result THEN
 * (5)     IF subject x is running in "deny read instead of demote" mode THEN
 * (6)        RETURN read denied
 * (7)     ENDIF
 * (8)     IF subject x is not running in "never demote" mode THEN
 * (9)        demote subject x
 * (10)    ENDIF
 * (11) ENDIF
 * (12) perform read on object y
 *   
 *
 * Example 2:  subject x writes object y.
 * (50) a = LOMAC attributes of subject x
 * (51) b = LOMAC attributes of object y
 * (52) IF lomac_must_deny( a, b ) THEN
 * (53)         return write denied
 * (54) ELSE
 * (55)         perform write operation on object y
 * (56) ENDIF
 *
 * Lines 1, 2, 50, and 51 show the architecture-specific code
 * constructing instances of lattr_t.
 *
 * Lines 5 and 8 ask "is the subject running in some mode?"  (See note
 * on modes, below.)  The architecture-specific code must use these
 * modes to determine when to call lomac_must_demote/deny() and when not
 * to.
 *
 * Lines 6, 9, 53 and 55 show the architecture-specific code
 * taking different actions depending on the results of calls to
 * lomac_must_demote/deny().  The architecture-specific code is responsible
 * for calling lomac_must_demote/deny() in the proper places, and carrying
 * out the appropriate demotions and denials depending on the result.
 *
 *
 * A NOTE ON LEVELS:
 *
 * LOMAC presently supports only two levels: 1 and 2.  Future versions
 * of LOMAC may support more levels.  Architecture-specific code may
 * assume that the LOWEST and HIGHEST constants defined below will
 * always refer to the lowest and highest levels in the range.  They
 * may also provide support for only two levels for the time being.
 * However, architecture-specific code should try to minimize any other
 * assumptions about levels, in order to make it easier to increase
 * the level range in the future.
 *
 *
 * A NOTE ON CATEGORIES:
 *
 * The lattr_t structure's `flags' field is intended to be a bitfield
 * which architecture-specific code can use to implement categories.
 * The lomac_must_deny() function interprets the bits in the flags field
 * as categories.  A clear flags field means no categories.
 *
 * A NOTE ON MODES:
 *
 * LOMAC allows subjects to run in many modes, such as "never demote"
 * or "no demote on IPC reads".  Support for these modes is entirely
 * the responsibility of the architecture-specific code, because the
 * architecture-independent code doesn't know about operations like
 * "read" or "read on an IPC object".
 *
 *************************************************************************/

typedef enum {
	LOMAC_LOWEST_LEVEL = 1,
	LOMAC_HIGHEST_LEVEL = 2
} level_t;


typedef struct {
  level_t level;             /* level (an integer range) */
  unsigned int flags;        /* category flags */
} lattr_t;                   /* lomac attribute structure type */


/* lomac_must_demote()
 *
 * in:     actor  - attributes of a subject that has or will perform an
 *                  operation that may require LOMAC to demote it.
 *         target - attributes of the object that is or was the operand.
 * out:    nothing
 * return: value   condition
 *         -----   ---------
 *           0     LOMAC should not demote the subject
 *           1     LOMAC should demote the subject
 *
 * This function is a predicate which decides whether or not LOMAC should
 * demote the subject with attributes `actor' after it performs an operation
 * (probably some kind of a read operation) on the object with attributes 
 * `target'.
 *
 */

static __inline int lomac_must_demote( const lattr_t *actor, 
				       const lattr_t *target ) {
	return( ( actor->level > target->level ) );
}


/* lomac_must_deny()
 *
 * in:     actor  - attributes of a subject that wants to perform some
 *                  operation that requires LOMAC to make an allow/deny
 *                  decision.
 *         target - attributes of the subject or object the above subject
 *                  will operate upon.
 * out:    nothing
 * return: value     condition
 *         -----     ---------
 *           0       LOMAC should allow the operation
 *           1       LOMAC should deny the operation
 *
 * This function is a predicate which decides whether or not LOMAC should
 * allow the subject with attributes `actor' to perform some operation
 * (probably some kind of write or kill operation) on the subject or object
 * with attributes `target'.
 *
 * The flags are two words: the low word is to be used for categories,
 * and the high word is meant to hold implementation-dependent flags that
 * are not category-related.
 *
 */

static __inline int lomac_must_deny( const lattr_t *actor,
				     const lattr_t *target ) {

	if( actor->level >= target->level ) {
		return 0;            /* allow */
	}
	if( target->flags & 0xffff ) {
		if( ( actor->flags & target->flags & 0xffff ) ==
		    ( target->flags & 0xffff ) ) {
			return 0;    /* allow */
		}
	}

	return 1;                    /* deny */
}

#endif /* lomac.h */
OpenPOWER on IntegriCloud