diff options
author | Casey Schaufler <casey@schaufler-ca.com> | 2011-01-17 08:05:27 -0800 |
---|---|---|
committer | Casey Schaufler <casey@schaufler-ca.com> | 2011-01-17 08:05:27 -0800 |
commit | 7898e1f8e9eb1bee88c92d636e0ab93f2cbe31c6 (patch) | |
tree | d4aaa367bb42d0ff9d1e4ba227f248b5b9cd7687 /security/smack/smack.h | |
parent | aeda4ac3efc29e4d55989abd0a73530453aa69ba (diff) | |
download | linux-stable-7898e1f8e9eb1bee88c92d636e0ab93f2cbe31c6.tar.gz linux-stable-7898e1f8e9eb1bee88c92d636e0ab93f2cbe31c6.tar.bz2 linux-stable-7898e1f8e9eb1bee88c92d636e0ab93f2cbe31c6.zip |
Subject: [PATCH] Smack: mmap controls for library containment
In the embedded world there are often situations
where libraries are updated from a variety of sources,
for a variety of reasons, and with any number of
security characteristics. These differences
might include privilege required for a given library
provided interface to function properly, as occurs
from time to time in graphics libraries. There are
also cases where it is important to limit use of
libraries based on the provider of the library and
the security aware application may make choices
based on that criteria.
These issues are addressed by providing an additional
Smack label that may optionally be assigned to an object,
the SMACK64MMAP attribute. An mmap operation is allowed
if there is no such attribute.
If there is a SMACK64MMAP attribute the mmap is permitted
only if a subject with that label has all of the access
permitted a subject with the current task label.
Security aware applications may from time to time
wish to reduce their "privilege" to avoid accidental use
of privilege. One case where this arises is the
environment in which multiple sources provide libraries
to perform the same functions. An application may know
that it should eschew services made available from a
particular vendor, or of a particular version.
In support of this a secondary list of Smack rules has
been added that is local to the task. This list is
consulted only in the case where the global list has
approved access. It can only further restrict access.
Unlike the global last, if no entry is found on the
local list access is granted. An application can add
entries to its own list by writing to /smack/load-self.
The changes appear large as they involve refactoring
the list handling to accomodate there being more
than one rule list.
Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
Diffstat (limited to 'security/smack/smack.h')
-rw-r--r-- | security/smack/smack.h | 9 |
1 files changed, 6 insertions, 3 deletions
diff --git a/security/smack/smack.h b/security/smack/smack.h index 129c4eb8ffb1..e365d455ceb6 100644 --- a/security/smack/smack.h +++ b/security/smack/smack.h @@ -52,13 +52,16 @@ struct socket_smack { struct inode_smack { char *smk_inode; /* label of the fso */ char *smk_task; /* label of the task */ + char *smk_mmap; /* label of the mmap domain */ struct mutex smk_lock; /* initialization lock */ int smk_flags; /* smack inode flags */ }; struct task_smack { - char *smk_task; /* label used for access control */ - char *smk_forked; /* label when forked */ + char *smk_task; /* label for access control */ + char *smk_forked; /* label when forked */ + struct list_head smk_rules; /* per task access rules */ + struct mutex smk_rules_lock; /* lock for the rules */ }; #define SMK_INODE_INSTANT 0x01 /* inode is instantiated */ @@ -202,7 +205,7 @@ struct inode_smack *new_inode_smack(char *); /* * These functions are in smack_access.c */ -int smk_access_entry(char *, char *); +int smk_access_entry(char *, char *, struct list_head *); int smk_access(char *, char *, int, struct smk_audit_info *); int smk_curacc(char *, u32, struct smk_audit_info *); int smack_to_cipso(const char *, struct smack_cipso *); |