'\" t
.TH "BUXTON\-SECURITY" "7" "" "buxton 1" "buxton\-security"
.\" -----------------------------------------------------------------
.\" * Define some portability stuff
.\" -----------------------------------------------------------------
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.\" http://bugs.debian.org/507673
.\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.ie \n(.g .ds Aq \(aq
.el       .ds Aq '
.\" -----------------------------------------------------------------
.\" * set default formatting
.\" -----------------------------------------------------------------
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.ad l
.\" -----------------------------------------------------------------
.\" * MAIN CONTENT STARTS HERE *
.\" -----------------------------------------------------------------
.SH "NAME"
buxton\-security \- Outline of buxton security model

.SH "DESCRIPTION"
.PP
Buxton uses a Mandatory Access Control (MAC) system to secure
configuration storage elements, namely, groups and keys within these
groups\&. MAC is enforced by using the
\m[blue]\fBSmack\fR\m[]\&\s-2\u[1]\d\s+2
Linux Security Module\&.

Each group and key that exists in buxton's configuration storage has
a Smack label associated with it\&. The label set by buxton is taken
from the Smack label of the running process (client) that created the
original group or key\&. If the label for a group or key should be
changed after initial group or key creation, a client with
appropriate privilege (UID 0) may modify it using
\fBbuxton_set_label\fR(3) or the "set\-label" command of
\fBbuxtonctl\fR(1)\&.

MAC is enforced for nearly all types of access requested by
clients\&. When enforcement is in effect, buxton consults the list of
Smack rules, managed by the Smack LSM, to make an access decision\&.
The table below lists the checks in effect for every buxton
command\&.

.B Table\ \&1.\ \&Access check grid
.TS
allbox tab(:);
lB lB.
T{
Command
T}:T{
Access checks
T}
.T&
l l
l l
l l
l l
l l
l l.
T{
set\-value (int32, bool, etc\&.)
T}:T{
Check read/write access on the group, and if the key exists, check
read/write access on the key\&.
T}
T{
get\-value (int32, bool, etc\&.)
T}:T{
Check read access on the group, and check read access on the key\&.
T}
T{
unset\-value
T}:T{
Check read/write access on the group and on the key\&.
T}
T{
create\-group
T}:T{
For system layers, check for UID 0\&. For user layers, no permission
checks are needed\&.
T}
T{
remove\-group
T}:T{
For system layers, check for UID 0\&. For user layers, check write
access on the group\&.
T}
T{
set\-label
T}:T{
For system layers, check for UID 0\&. Action is not allowed for user
layers\&.
T}
.TE

.sp 1

.PP
Since buxton uses layers to store sets of groups and keys, and
identical group/key sets may exist across all layers, fine\-grained
access control is achievable by setting appropriate Smack labels on
groups and keys for the targeted layer\&. For a more detailed
discussion of the interaction of group/key labels and the layer
model, see \fBbuxton\-layers\fR(7)\&.

.SH "COPYRIGHT"
.PP
Copyright 2014 Intel Corporation\&. License: Creative Commons
Attribution\-ShareAlike 3.0 Unported\s-2\u[2]\d\s+2\&.

.SH "SEE ALSO"
.PP
\fBbuxton\fR(7),
\fBbuxtonctl\fR(1),
\fBbuxtond\fR(8),
\fBbuxton\-api\fR(7)

.SH "NOTES"
.IP " 1." 4
Smack
.RS 4
\%https://www.kernel.org/doc/Documentation/security/Smack.txt
.RE
.IP " 2." 4
Creative Commons Attribution\-ShareAlike 3.0 Unported
.RS 4
\%http://creativecommons.org/licenses/by-sa/3.0/
.RE