> -----Original Message----- > From: Schaufler Casey (Nokia-MS/SiliconValley) > Sent: Monday, January 17, 2011 11:31 AM > To: [email protected] > Cc: Schaufler Casey (Nokia-MS/SiliconValley); Sakkinen Jarkko.2 (EXT- > Tieto/Tampere); Karhunen Janne (Nokia-MS/Helsinki); Reshetova Elena > (Nokia-MS/Helsinki) > Subject: [PATCH 4/4] Smack: mmap controls
This patch is now in James Morris' security-testing#next > > git://gitorious.org/smack-next/kernel.git > > commit 7898e1f8e9eb1bee88c92d636e0ab93f2cbe31c6 > Author: Casey Schaufler <[email protected]> > Date: Mon Jan 17 08:05:27 2011 -0800 > > 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 <[email protected]> > --- > include/linux/xattr.h | 2 + > security/smack/smack.h | 9 +- > security/smack/smack_access.c | 52 ++++-- > security/smack/smack_lsm.c | 269 +++++++++++++++++++++++++----- > security/smack/smackfs.c | 370 ++++++++++++++++++++++++++++----- > -------- ... _______________________________________________ MeeGo-kernel mailing list [email protected] http://lists.meego.com/listinfo/meego-kernel
