RBAC AND ARBAC POLICIES FOR A UNIVERSITY
  Scott D. Stoller, Ping Yang, C.R. Ramakrishnan, and Mikhail I. Gofman
			      12 August 2007

********************
REALISM AND SCOPE

This policy is fairly realistic, except for some simplifications that do
not affect the structural properties relevant to our algorithms (e.g.,
number of positive preconditions in each can_assign rule, and use of
negation).

the main simplification is that we do not use a framework with
parameterized roles and objects, so we consider one department, one
course, one gradebook, etc.  it would be easy to add parameters (such
as department name and course number) to the policy, instantiate the
parameters with appropriate sets of values, and then apply our analysis
algorithms.  of course, developing truly parametric analysis algorithms
would be more difficult.

we consider administration of the user assignment only, by defining a
can_assign relation.  this seems like the right way to start, since the
user assignment changes more often.  administration of the permission
assignment and the role hierarchy are topics for future work.

ARBAC97 expresses the can_assign relation in terms of administrative
permissions on role ranges; this is more robust to changes in the role
hierarchy.  since we do not consider changes to the role hierarchy, we
adopt a simpler ARBAC framework without role ranges.

the plans produced by policy analysis may improve the analyst's
understanding of the policy, even if some of the plans do not represent
attacks of concern in practice.  our algorithms can easily provide
multiple plans.

******************************
STUDENTS

ROLES (10)

Student, Undergrad, Grad, TA, RA, Grader, GradStudOfficer, HonorsStudent, 
GradCommittee, UndergradPermittedGradClass

ROLE HIERARCHY

Student < Undergrad
        < Grad

note: generally, role hierarchy is useful only if users may be assigned to
the senior role without also being assigned to the junior role.  the
preconditions in the can_assign rules below require that students are
added first to Grad or Undergrad, and then to TA, RA, or Grader,
reflecting the fact that admission decisions are made first, followed by
financial support decisions.  consequently, the following inheritance
relations, although reasonable and harmless, would have no real effect on
users' permissions, because students would be explicit members of both the
junior role and the senior role: Grad < TA, Grad < RA, Undergrad < Grader.
for brevity, we omit these inheritance relationships.

PERMISSION ASSIGNMENT

these tuples are grouped and alphabetized by role.

PA(Grad, [register, GradClass])
PA(Grad, [withdraw, GradClass])
PA(Grad, [enroll, StudentHealthInsur])

PA(Grader, [assignGrade, GradeBook])
PA(Grader, [viewGrade,   GradeBook])

PA(GradStudOfficer, [reserveRoom, RoomSchedule])

PA(HonorsStudent, [register, UndergradHonorsClass])
PA(HonorsStudent, [withdraw, UndergradHonorsClass])

PA(Student, [viewGrade, GradeBook])
PA(Student, [create,    ComputerAccount])
PA(Student, [obtain, StudentParkingPermit])
PA(Student, [register, Course])
PA(Student, [pay, Tuition])

PA(TA, [assignGrade, GradeBook])
PA(TA, [viewGrade,   GradeBook])

PA(Undergrad, [register, UndergradClass])
PA(Undergrad, [withdraw, UndergradClass])
PA(UndergradPermittedGradClass, [register, GradClass])
PA(UndergradPermittedGradClass, [withdraw, GradClass])

note: a faculty can assign an undergrad to UndergradPermittedGradClass to
give that student permission to register for grad classes.  in a
framework with parameters, permission would be given to register for
specific grad classes.


ADMINISTRATIVE POLICY: can_assign rules for assignment to student roles

can_assign(AdmissionsOfficer, true, Undergrad)

can_assign(DeptChair, Grad,      TA)
can_assign(DeptChair, Grad,      GradStudOfficer)
can_assign(DeptChair, GradStudOfficer, GradCommittee)
can_assign(DeptChair, Undergrad, Grader)

can_assign(Faculty, Student, RA)

can_assign(GradAdmissionsCommittee, true, Grad)

can_assign(HonorsPgmDirector, Undergrad, HonorsStudent)

can_assign(Faculty, Undergrad, UndergradPermittedGradClass)


******************************
EMPLOYEES

**** ROLES (23)

AdmissionsOfficer, AssistantProf, AssociateProf, Dean, DeanOfAdmissions,
DeptChair, Employee, FacilitiesCommittee, FacilitiesDirector, Faculty,
FullTimeEmployee, GradAdmissionsCommittee, HonorsPgmDirector, Lecturer,
President, Professor, Provost, QualExamCommittee, QualExamCommitteeHead,
Staff, TenuredFac, AsstForStudentAffairs

note: an AdmissionsOfficer works in the university's undergraduate
admissions office.  Dean is the dean of the college containing the
department of interest.  the following are departmental committees:
FacilitiesCommittee, GradAdmissionsCommittee, GradCommittee (oversees the
graduate curriculum), QualExamCommittee (oversees the qualifying exam
taken by all Ph.D. students and some M.S. students).

**** ROLE HIERARCHY

Employee < Staff < AdmissionsOfficer < DeanOfAdmissions < Provost
         < Faculty < Lecturer
                   < AssistantProf < AssociateProf < Professor < DeptChair < Dean < Provost < President

TenuredFac < AssociateProf
           < Professor

FacilitiesCommittee < FacilitiesDirector

QualExamCommittee < QualExamCommitteeHead

note: Employee < FullTimeEmployee, Faculty < QualExamCommittee, etc., are
unnecessary for essentially the same reason as Grad < TA: they have no
effect on employees' permissions, because the preconditions of can_assign
rules ensure that every user appointed to the senior role is already
assigned to the junior role or a role that inherits from it.

note: Faculty < TenuredFac is unnecessary because users are not assigned
explicitly to TenuredFac.  TenuredFac exists only to capture the
permissions common to all tenured faculty.

**** PERMISSION ASSIGNMENT

PA(Dean,                  [authorizeExpenditure, CollegeAcct])
PA(Dean,                  [approveLateWithdrawal, Roster])
PA(Dean,                  [approveGradeChange, GradeBook])

PA(AsstForStudentAffairs, [allowLateWithdrawal, Roster])
PA(AsstForStudentAffairs, [approveGradeChange, GradeBook])

note: grade changes are submitted by the instructor and then require
approval by the Dean or the Dean's assistant for student affairs.

PA(DeptChair, [modify, DeptBudget])

PA(FacilitiesDirector, [authorizeEquipmentPurchase, DeptAcct])

PA(Employee, [obtain, EmployeeParkingPermit])

PA(Faculty, [assignGrade, GradeBook])
PA(Faculty, [submitGradeChange, GradeBook])
PA(Faculty, [submitGrades, GradeBook])
PA(Faculty, [reviseGrade, GradeBook])
PA(Faculty, [viewGrade,   GradeBook])

note: submitGrades makes the grades available to the registrar and
students.  reviseGrade is used to change a grade before that.
to change a grade after that, the instructor does submitGradeChange, and
then the Dean does approveGradeChange.

PA(FullTimeEmployee, [enroll, EmployeeHealthInsur])

PA(President, [authorizeExpenditure, UniversityAcct])

PA(Provost,   [authorizeExpenditure, UniversityAcct])


**** ADMINISTRATIVE POLICY: can_assign rules for assignment to employee roles

can_assign(Dean, Professor and not Dean and not Provost, DeptChair)

note: including "and not Provost" in the precondition is unnecessary,
because "not Dean" implies "not Provost", becase Dean < Provost, and the
semantics of preconditions reflects implicit (as well as explicit)
membership.

can_assign(Dean, Staff, AsstForStudentAffairs)

note: the Dean appoints members of his staff to the AsstForStudentAffairs
role to delegate to them permissions for dealing with routine tasks such
as approving late withdrawals and grade changes.

note: our policy gives the President inherited permissions to assign and
revoke department chairs, but does not require the President to approve
the Dean's appointments of department chairs.  I'm not sure whether the
President actually needs to approve such appointments; this could easily
be modeled if appropriate.  Same comments for the Provost's appointments
of Deans.

can_assign(DeanOfAdmissions, Staff, AdmissionsOfficer)

can_assign(DeptChair, Faculty,       GradAdmissionsCommittee)
can_assign(DeptChair, Faculty,	     GradCommittee)
can_assign(DeptChair, Faculty,       HonorsPgmDirector)
can_assign(DeptChair, Employee,      FacilitiesCommittee)
can_assign(DeptChair, Faculty,       FacilitiesDirector)
can_assign(DeptChair, Faculty,       QualExamCommittee)
can_assign(DeptChair, GradCommittee, QualExamCommitteeHead)

note: members of the FacilitiesCommittee may be Faculty or Staff; this is
reflected by using Employee as the precondition for assignment to the
committee.

note: the can_assign rule for FacilitiesDirector could be changed to:
can_assign(Faculty /\ FacilitiesCommittee, FacilitiesDirector).
however, since FacilitiesDirector inherits from FacilitiesCommittee,
there is no reason to require that a faculty be explicitly assigned to
both FacilitiesCommittee and FacilitiesDirector.

can_assign(President, true, r) 
  for r in {Staff, DeanOfAdmissions,
            Lecturer, AssistantProf, AssociateProf, Professor}

notes: Employee is omitted here because all employees are appointed to
more specific roles, not to Employee.  DeptChair, Dean, and Provost are
omitted here because users should be assigned first to Professor (using
this rule) and then to those roles (using other rules).
AdmissionsOfficer is omitted here because President inherits (from
DeanOfAdmissions) permission to assign to AdmissionsOfficer.

notes: the policy does not model the recommendation process that
influences the president's decision to assign (or revoke) users to faculty
roles, because the recommendation process involves voting, which is not
expressible in common RBAC/ARBAC frameworks.  the policy does not include
a can_assign rule for President; I think the Board of Trustees appoints
the President.

can_assign(President, Employee, FullTimeEmployee)

note: a new hire is first assigned to the appropriate position (e.g.,
Staff or AsstProfessor) and then, if appropriate, to FullTimeEmployee.
there is no real need for this sequentiality, but the RBAC API does not
contain a primitive operation to assign a user to multiple roles at once,
so the assignments must occur in some order.

can_assign(President, Professor and not DeptChair, Provost)

note: including "and not Dean" in the precondition is unnecessary, because
"not DeptChair" implies "not Dean", becase DeptChair < Dean, and the
semantics of preconditions reflects implicit (as well as explicit)
membership.

can_assign(Provost, Professor and not DeptChair, Dean)

note: including "and not Provost" in the precondition is unnecessary,
because "not DeptChair" implies "not Provost", becase DeptChair < Provost,
and the semantics of preconditions reflects implicit (as well as explicit)
membership.

note: the explicit negative preconditions in the rules for assignment to
DeptChair, Dean, and Provost do not enforce separation of duty, because
DeptChair < Dean < Provost (so a single user can have the permissions of
all three of these roles).  instead, those negative preconditions model
the policy that a user should not be an explicit member of any two of
those roles.  this is a real policy (I believe), although it is not a
separation-of-duty requirement.  is it useful to model this aspect of the
real policy?  note that it is useful unless it is *obvious* (not merely
*true*) that none of our queries are affected by the presence of these
negative preconditions.  there is an example below of a query whose answer
is affected (to find it, search for "not D"), although it is not the most
interesting query.

******************************
ADMINISTRATIVE POLICY: can_revoke

in general, each administrator can revoke users from the same roles to
which he can assign users.  in order words, for each rule can_assign(r_a,
c, r), there is usually a corresponding rule can_revoke(r_a, r).  the
exceptions are:

  the Dean can revoke the Undergrad and Grad roles (i.e., expel
  students); AdmissionsOfficer and AdmissionsCommittee cannot.

******************************
ADMINISTRATIVE POLICY: SMER CONSTRAINTS

SMER(Undergrad, Grad)
SMER(AdmissionsOfficer, GradAdmissionsCommittee)

note: this SMER constraint is motivated by a separation of duty property,
namely, we expect a single user cannot admit both grad and undergrad
students.

note: we omit constraints like SMER(Student, Employee) because employees
are permitted to take classes.  we omit constraints like SMER(Staff,
Faculty) because they would force Provost and President to be empty.  we
omit constraints like SMER(AsstProf, AssocProf) because they would force
AssocProf to be empty.

recall that SMER constraints take implicit role membership into account.
even if we weakened the definition of SMER constraint to ignore implicit
role memberships, constraints like SMER(AsstProf, AssocProf) would not
enforce any separation of duty, because a member of AssocProf already has
the permissions of AsstProf and AssocProf.  the intention of such SMER
constraints is partly captured by the negative preconditions in the
can_assign rules for appointments to Provost and Dean.

when we transform the policy to eliminate role hierarchy, the SMER
constraints become:

SMER(Undergrad, Grad)
SMER(r, GradAdmissionsCommittee) for r in [AdmissionsOfficer,President]

note: we used ARBAC97's role range notation here.

******************************
UNCONDITIONAL REVOCATION 

non-trivial preconditions for revocation generally seem unnecessary.
indeed, ARBAC97 does not support preconditions for revocation.  Sandhu
et al. give an example where preconditions for revocation could be
useful, but omit that feature from ARBAC97, pending more evidence that
it is worthwhile \cite{sandhu97arbac}.  the model in our CSFW 2006
paper allows such preconditions, with the following motivating example:
can_revoke(Dean, not TA, Grad).  this requires that a student is removed
from the TA role before being expelled.  this is reasonable, but there
are alternative ways to achieve the same effect.  the real goal is to
ensure that the expelled student is removed from all roles; the order
of removals is irrelevant.  this will be easily and reliably achieved
if the ARBAC API provides an operation that removes a user from all
roles, and the Dean uses it when expelling students.

******************************
CHANGES TO ADMINISTRATORS' ROLES

in ARBAC97, regular roles and administrative roles are distinguished, and
administrative actions assign and revoke only regular roles.  therefore,
when evaluating reachability, \ie, whether some administrators (\ie, users
in administrative roles) can assign a target user to the (regular) roles
in the goal, it suffices to consider changes to the roles of the target
user; the roles of the administrators never change.

in [sasturkar06policy], there is no formal distinction between regular
roles and administrative roles.  this is motivated by the observation that
in some case studies, such as the university policy, there are roles, such
as Faculty and DeptChair, that naturally have both regular permissions and
administrative permissions.  therefore, we consider that there is a single
set of roles.  whether a role is being used as an administrative role,
regular role, or both depends on its permissions.

definition: a role ar is an "administrative role" if it has some
administrative permissions, i.e., can_assign(ar, c, r) holds for some c
and r.

definition: a role r is a "regular role" if it has some regular
permissions, i.e., PA(r, p) holds for some p.

these definitions allow a role to be both a regular role and an
administrative role.  a consequence is that administrative actions can
assign and revoke administrative roles.

nevertheless, the policy analysis questions in [sasturkar06policy] are
formulated to consider only changes to the roles of the target user, not
the administrators.  while this is a helpful simplification for initial
work, we consider here the more general problem in which adminstrators'
roles may change.  

we start with an example that illustrates the impact of this.  consider
the analysis question:

  can an administrator initially in DeptChair assign a user initially
  in Undergrad to HonorsStudent?

if we consider only role changes for the target user, the answer is "no",
because only HonorsPgmDirector can assign users to HonorsStudent, and the
initial state UA in that algorithm only reflects the roles of the target
user (in this example, UA = {Undergrad}).  however, this ignores the fact
that a user in DeptChair can assign himself to the administrative role
HonorsPgmDirector; note that Faculty < DeptChair, so the precondition of
the rule can_assign(DeptChair, Faculty, HonorsPgmDirector) holds for this
assignment.  therefore, an administrator initially in DeptChair can indeed
assign a user initially in Undergrad to HonorsStudent.

if negative preconditions (for assignments to administrative roles) are
allowed, analysis problem instances must specify the set of administrators
and the initial roles of each administrator (and the target user), and the
analysis must track the role assignment for each administrator (and the
target user); it is not sufficient to consider only the union of the sets
of roles of the administrators.  \comment{ for example, suppose role AR1
cannot be revoked, and SMER(AR1,AR2), and can_assign(AR1, true, AR2), and
can_assign(AR2, true, R0).  suppose the question is whether two
administrators A1 and A2 can assign a user U0 to role R0, when A1 is
initially in AR1, and A2 and U0 are initially in no roles.  suppose we
merge A1 and A2 into a single implicit administrator, initially in AR1.
then the answer is "no", because the single administrator cannot assign
himself to AR2, because of the SMER constraint.  however, this is not the
correct answer to the original problem.  actually, A1 can assign A2 to
AR2, and then A2 can assign U0 to R0.}

in many cases, considering changes to administrators' roles does not
affect the analysis result.  we propose easily checked sufficient
conditions for this.  when these conditions are satisfied, the analysis
only needs to track one set of roles.  this can greatly reduce the cost of
the analysis.

we also give algorithms for the more general reachability problem in which
changes to administrators' roles are allowed.

******************************
CHARACTERISTICS OF THE UNIVERSITY POLICY

Negative Preconditions (including SMER).

see statistics below.  explicit negation is applied to 3 roles (DeptChair,
Dean, and Provost).  there are also a few SMER constraints.  negative and
positive roles are counted after the transformation to eliminate role
hierarchy.  role hierarchy relationships described above as "unnecessary"
are omitted.

Positive Preconditions.

every can_assign rule has at most one positive precondition, i.e., |ppre|
<= 1.  in part, this is because positive preconditions are imposed
sequentially, rather than simultaneously.  for example, a user is
appointed to Grad then GradStudOfficer then GradCommittee, so there is no
need to include Grad as a positive precondition of GradCommittee.

the following roles are positive, before expanding role hierarchy: Grad,
GradStudentOfficer, Undergrad, Staff, Professor, Faculty, Employee,
GradCommittee.  after expanding role hierarchy, several more roles are
positive, because many roles are senior to Employee.

Disjunction.

a policy has disjunction for a role r if there are multiple can_assign
rules with target r.  this policy contains no disjunction before the
transformation to eliminate role hierarchy.  the transformation introduces
disjunction for a role r if there is a rule can_assign(ar, c, r) such that
ar < ar' for some role ar'.  the transformed policy contains disjunction
for 12? (might not be up-to-date) out of 32 roles.

Hierarchical Role Assignment.

the policy has hierarchical role assignment with respect to all sets of
administrative roles except (1) sets containing DeptChair and not
GradAdmissionsCommittee (because GradAdmissionsCommittee can assign to
Grad, and DeptChair can't), and (2) sets containing DeptChair and not
HonorsPgmDirector (because HonorsPgmDirector can assign to HonorsStudent,
and DeptChair can't).  we conclude that analysis algorithms that assume
hierarchical role assignment are adequate for analyzing most reachability
properties of the university policy.

Total Revocation (TR).  

if we ignore the part of the policy that violates hierarchical role
assignment, so we can pretend the policy satisfies separate
administration, and slice the policy based on the set A of administrative
roles in the initial state, then TR holds for all problem instances such
that: (AdmissionsOfficer in A or GradAdmissionsCommittee in A) => Dean in
A.  for sets A not satisfying this condition, Undergrad or Grad can be
assigned but not revoked.  note: for any set A, the number of irrevocable
roles is at most 2.


# of roles: 32
# of negative roles (after expanding role hierarchy): 8/32 = 25%
# of positive roles (after expanding role hierarchy: 22/32 = 69%
# of administrative roles: 11

# of can_assign rules before expanding role hierarchy: 28
# of can_assign rules after expanding role hierarchy: 106

# of can_assign rules per role (after expanding role hierarchy):
4/32 have 0 rule - around 12%
17/32 have 1 rule - around 53%
1/32 have 2 rule - around 3%
1/32 have 3 rule - around 3%
2/32 have 5 rule - around 6%
4/32 have 9 rule - around 13%
1/32 have 10 rule - around 3%
2/32 have 14 rule - around 6%

# of preconds per can_assign rule (after expanding role hierarchy):
8/106 rules - no precond - around 7.5%
79/106 rules - 1 pos pre - around 74%
5/106 rules - 1 pos + 1 neg - around 5%
9/106 rules - 1 pos + 2 neg - 8.5%
2/106 rules - 1pos + 3 neg - around 2%
2/106 rules - 1 pos + 4 neg - around 2%
1/106 rules - 1 neg - around 1%


******************************
SAMPLE ANALYSIS QUESTIONS

***** User-Role Reachability

as mentioned above, an analysis problem instance specifies the initial
roles of each administrator, as well as the initial roles of the target
user (i.e., the user to be assigned to the roles in the goal) and the
goal.

when the initial state is not specified explicitly, the default initial
state has one administrator in every role with an administrative
permission (i.e., every role that appears as the first argument to
can_assign in some rule), and a target user initially in no roles.  note
that the administrators together have enough administrative power to add
users to all reachable roles, so it is safe to start the target user in no
roles.

can a user initially in Faculty and a user initially in Undergrad
together assign the latter user to HonorsStudent?

answer: no.

can a user initially in DeptChair and a user initially in Undergrad
together assign the latter user to HonorsStudent?

note: this problem instance does not satisfy hierarchical role assignment,
\ie, the policy does not have hierarchical role assignment with respect to
{DeptChair,Undergrad}.

answer: yes.  the administrator in DeptChair can assign himself to
HonorsPgmDirector (the precondition is satisfied because Faculty <
DeptChair), and then assign the undergrad to HonorsStudent.  

to illustrate that it is sometimes necessary to have two administrators to
reach a goal.  suppose we added a negative precond "not DeptChair" to the
can_assign rule for HonorsPgmDirector (after all, we don't want the chair
to be overworked :-).  now consider the same query:

can a user initially in DeptChair and a user initially in Undergrad
together assign the latter user to HonorsStudent?

note: this problem instance does not satisfy hierarchical role assignment.

answer: no.  only HonorsPgmDirector can add users to HonorsStudent.  the
DeptChair cannot assign himself to HonorsPgmDirector, because of the
negative precondition "not DeptChair".  the DeptChair cannot assign the
student to HonorsPgmDirector, because of the positive precondition
"Faculty".

now add a second administrator, and see the answer change.

can a user initially in DeptChair, a user initially in {Faculty}, and a
user initially in Student together assign the third user to HonorsStudent?

note: this problem instance does not satisfy hierarchical role assignment.

answer: yes, because the DeptChair can assign the Faculty to
HonorsPgmDirector.

we could consider variants of reachability analysis, such as: what is the
minimum number of administrators that must collaborate to achieve a
certain role assignment.  a semi-decision procedure for this problem is
easily obtained by calling our existing reachability algorithm on
appropriate problem instances with increasing numbers of administrators
(and with appropriate initial roles for each administrator).

can a user initially in Provost and a user initially in DeptChair
together assign the latter user to Dean?

answer: no.  recall that "not DeptChair" is a precondition for assignment
to Dean (without this precondition, the answer to this query would be
yes).  the Provost can remove the user from DeptChair, but the Provost
cannot then add him to Professor, which is the positive precondition for
assignment to Dean.  on the other hand, a user in DeptChair would normally
also be in Professor.  so we consider the following analysis question.

can a user initially in Provost and a user initially in {Professor,
DeptChair} together assign the latter user to Dean?

answer: yes.  the Provost can remove the user from DeptChair, and then add
him to Dean.

can a user initially in President and a user initially in {Professor,
DeptChair} together assign the latter user to {DeptChair, Dean}?

answer: yes.  this might seem surprising, since DeptChair and Dean are
negative preconditions for each other.  however, the semantics of goals
(and positive preconditions) in the presence of role hierarchy is that
they are satisfied by implicit membership.  since DeptChair < Dean, this
goal is satisfied if the user can be assigned to {Dean}.  the President
can do this by removing the user from DeptChair and adding the user to
Dean.

recall the rule

can_assign(President, true, r) 
  for r in {Staff, AdmissionsOfficer, DeanOfAdmissions, ...}

we initially wrote the part of this rule for assignments to staff roles
using ARBAC97 range notation as: can_assign(President, true, [Staff,
President)).  however, multiple inheritance tricked us: we remembered Dean
< Provost but forgot DeanOfAdmissions < Provost, so we overlooked the fact
that this role range includes Provost.  we intended to exclude Provost
here, because there is a separate rule with positive and negative
preconditions for assignment to Provost (thus, this role range would be
incorrect even if we eliminated the negative preconditions from the rule
for assignment to Provost).  unfortunately, this kind of error cannot be
caught by reachability queries that do not distinguish implicit and
explicit membership (e.g., note that {DeptChair, Provost} should be
reachable with that semantics for queries).  to detect this kind of error,
we need reachability queries that are interpreted with respect to explicit
membership only.  this is easily done by keeping the goal {r1,r2,...} as
is, instead of expanding it to Senior(r1) x Senior(r2) x ...

***** User-Permission reachability

given an initial state, a set P of permissions, and a target user, is
there a reachable state in which the target user has all the permissions
in P?

can a user initially in Dean and a user initially in Faculty together
assign the latter user to a role with permission approveGradeChange?

answer: no.  only AsstForStudentAffairs and Dean have that permission.
the Dean can't assign the user to AsstForStudentAffairs, because of the
precondition Staff.  also, the Dean can't assign the user to Dean.

note: this query partially captures the separation-of-duty property that
grade changes should be submitted and approved by different users.  the
current policy does not enforce this property, because the Dean can submit
and approve grade changes.  we do not attempt to enforce this property in
the current policy, because it might be awkward without role parameters.

from the default initial state, is there a reachable state in which the
target user has permissions {UserAssign(Undergrad), UserAssign(Grad)}?

answer: no, because of SMER(AdmissionsOfficer, GradAdmissionsCommittee).

notes: this query is one of the few whose answer is affected by the SMER
constraints.  this query illustrates that we allow user-permission queries
to ask about administrative permissions, as well as regular permissions.

from the default initial state, is there a reachable state in which the
target user has the permissions {[obtain, StudentParkingPermit], [obtain,
EmployeeParkingPermit]}?

answer: yes, because the policy does not require SMER(Student, Employee).

***** Precondition Queries

precondition queries for user-role reachability (or user-permission
reachability) return the "weakest preconditions" for specified
administrators to achieve a specified goal.  specifically, instead of
specifying the initial roles of the target user, the analysis problem is
to find minimal (with respect to subset) sets of initial roles of the
target user for which the goal is reachable.

what are the weakest preconditions for an administrator initially in
DeptChair to assign a user to HonorsStudent?

answer: {Undergrad}.  note that, if the user is not in Undergrad, the
DeptChair cannot assign him to Undergrad.

note: I couldn't easily think of an example in which the goal is a
singleton and the weakest precondition isn't.

***** Containment Properties

a role-role containment query has the form: given an initial state
(containing a set of administrators and their initial roles, and the
initial roles of the target users), is r1 contained in r2 in all
reachable states?"  the answer is yes if, in all reachable states, if
the target user is in r1, then the target user is also in r2.

the less constrained query "is r1 always contained in r2?" is
uninteresting, because the answer is always "no".  because this form of
query does not specify the initial state, we can always start (and end)
in a state in which some user is in r1 but not r2. in our framework, no
policy rule can prohibit such a state.

when the initial state is not specified explicitly, the default is the
same as for reachability queries.

Example: is TA contained in Grad?  No.  Although Grad is a precondition of
the can_assign rule for TA, preconditions are not invariants, as discussed
in detail in \cite[section 3.3]{sandhu97arbac}.  A user can be added to
Grad and then to TA, and then revoked from Grad while remaining in TA.  If
we allowed preconditions for can_revoke, and made "not TA" a precondition
for revoking Grad, then TA would be contained in Grad.

permission-role containment properties have the form: in all states
reachable from a given initial state, is every user with permission p in
some role in R?  where R is a set of roles.

Example: is every user with permission [assignGrade, GradeBook] in some
role in {TA, Faculty}?  no.  the user could be in Grader.

note: I feel that the examples of permission-permission containment have
not been particularly interesting.  if we don't think of more interesting
examples, perhaps we'll omit this kind of property or just mention it
briefly.  we can also consider administrative permission-permission
containment, e.g., does every user with permission "can assign to r1" also
have permission "can revoke from r1"?  I'm not sure whether this is more
interesting.  --scott

permission-permission containment properties have the form: in all
states reachable from a given initial state, does every user with
permission p1 also have permission p2?

Permission-permission containment: for target users initially in no
roles, does every user with permission [assignGrade, GradeBook] also
have permission [finalize, GradeBook]?  no.  users in TA and Grader can
assign grades but not finalize them.

****************************************
EXTENSIONS TO THE POLICY

extend the policy to model the DeptChair's permission to assign Faculty to
be instructors of classes.  this requires parameterized roles.

extend the policy to model approval of timesheets or travel expenses.
this involves SMER constraints.  here's a policy for submission of
timesheets, without using parameters in the policy.  an undergrad submits
a timesheet; a project director and supervisor must approve it.  all three
roles must be filled by different people.

PA(Student, [submit, Timesheet])
PA(ProjectDirector, [approveByProjDir, Timesheet])
PA(Supervisor,      [approveBySuper, Timesheet])

SMER(ProjectDirector, Supervisor)
SMER(ProjectDirector, Student)
SMER(Student, Supervisor)

can_assign(President, Employee, ProjectDirector)
can_assign(President, Employee, Supervisor)

extend the policy to model addition of new courses.  proposals for new
courses must be approved by all chairs and then by the dean.

extend the policy to model the Chancellor.  my impression is that the
Chancellor, unlike the President, is not a faculty, so we should not have
the inheritance relation President < Chancellor.

extend the policy to reflect the recommendation process for hiring and
promotion of faculty.  this requires extending the ARBAC framework to
model voting.  the recommendation process works as follows.  the
department has two promotion committees: one for tenure and promotion to
associate professor (only tenured faculty may be on this committee), and
one for promotion to professor (only professors may be on this committee).
the appropriate department committee makes a recommendation (i.e., a
non-binding decision).  the dept chair conveys it to the dean, who conveys
it to the college promotion and tenure committee (its members are
Professors), which makes its own recommendation.  the dean conveys it to
the provost.  the provost (or his committee, if he refers the matter to
them) makes a recommendation and conveys it to the president.  the
president makes a binding decision for promotion and a recommendation for
tenure, and conveys the latter to the chancellor.  the chancellor makes a
binding decision for tenure.  officially, the Board of Trustees must
approve these decisions, but it is a "rubber stamp" that can reasonably be
omitted from this policy.

a model of the recommendation process would start with roles representing
the committees (DeptPromotionToAssocCommittee,
DeptPromotionToProfCommmittee, CollegePromotionCommittee) and roles that
reflect committee recommendations (RecommendedForAssocProfByDept,
RecommendedForAssocProfByCollege, etc.).  however, assignment to both of
these kinds of roles may involve voting.  for example, Faculty vote to
assign (elect) users to the CollegePromotionCommittee, and
CollegePromotionCommittee votes to assign users to
RecommendedForAssocProfByCollege.  (note: in our department, all faculty
with the appropriate rank are members of the dept promotion committees; no
voting is involved.)  permission to vote on a particular kind of decision
could be represented in the permission assignment, e.g.,
PA(CollegePromotionCommittee,
vote(assign(RecommendedForAssocProfByCollege))).  or, we could represent
voting by special can_assign rules, e.g.,
majority_can_assign(CollegePromotionCommittee,
RecommendedForAssocProfByCollege).

extend the policy to model academic integrity procedures.  does this
involve voting by the academic integrity committee?

******************************************