> Whats the difference between add/remove and create/destroy?
>
> The devices are in a kind of hierarchy. You can now create one or more
> "master devices" (mouse cursor and keyboard focus). The physical input
> devices are "slave devices" that attach to master devices.
>
> Add/remove controls the ability to add/remove slave devices from a
> master device. Create/destroy controls the ability to create new master
> devices.
- rework: Add a comment of "deprecated" for deprecated permissions.
- bugfix: MCS policy did not constrain the following permissions.
db_database:{getattr}
db_table:{getattr lock}
db_column:{getattr}
db_procedure:{drop getattr setattr}
db_blob:{getattr import export}
- rework: db_table:{lock} is moved to reader side, because it makes
impossible to refer read-only table with foreign-key constraint.
(FK checks internally acquire explicit locks.)
- bugfix: some of permissions in db_procedure class are allowed
on sepgsql_trusted_proc_t, but it is a domain, not a procedure.
It should allow them on sepgsql_trusted_proc_exec_t.
I also aliased sepgsql_proc_t as sepgsql_proc_exec_t to avoid
such kind of confusion, as Chris suggested before.
- rework: we should not allow db_procedure:{install} on the
sepgsql_trusted_proc_exec_t, because of a risk to invoke trusted
procedure implicitly.
- bugfix: MLS policy dealt db_blob:{export} as writer-side permission,
but it is required whrn the largeobject is refered.
- bugfix: MLS policy didn't constrain the db_procedure class.
a xfrm policy. It also defines MLS policy for association { sendto,
recvfrom, polmatch }.
NOTE: When an inbound packet is not using an IPSec SA, a check is performed
between the socket label and the unlabeled sid (SYSTEM_HIGH MLS label). For
MLS purposes however, the target of the check should be the MLS label taken
from the node sid (or secmark in the new secmark world). This would present
a severe performance overhead (to make a new sid based on the unlabeled sid
with the MLS taken from the node sid or secmark and then using this sid as
the target). Pending reconciliation of the netlabel, ipsec and iptables contexts,
I have chosen to currently make an exception for unlabeled_t SAs if TE policy
allowed it. A similar problem exists for the outbound case and it has been similarly
handled in the policy below (by making an exception for unlabeled_t).
I am submitting the below limited patch pending a comprehensive patch from
Joy Latten at IBM (latten@austin.ibm.com).
I am not sure if I needed to manually do a "make tolib" in the flask subdir
and submit the results as well. Please let me know if I needed to.
Signed-off-by: Venkat Yekkirala <vyekkirala@TrustedCS.com>