SMACK: mandatory access control
cover SMACK: mandatory access control
Hi!
This small series adds support for SMACK, the Simplified Mandatory Access Control Kernel.
In computer security, a Mandatory Access Control is a mechanism where the operating system contrains the access to an object (file, socket, ...) by a subject (typically a process) according to rules. A well-known example is SELinux.
SMACK is an implementation of this mechanism, aimed towards simplicity. It can be used to harden embedded devices. It is currently used in Tizen.
This series introduces the "smack" package, which provides the user space library as well as the tools to manage the access rules. When selecting this package, the support for SMACK is actived in the kernel. SMACK is controlled via the pseudo file system /sys/fs/smackfs. Systemd can mount it automatically if compiled with SMACK support. So the systemd package has been updated accordingly.
Best regards,
ELB
Eric Le Bihan (2):
smack: new package.
systemd: add SMACK support option.
linux/linux.mk | 4 ++++ package/Config.in | 1 + package/smack/Config.in | 28 ++++++++++++++++++++++++++++ package/smack/smack.mk | 14 ++++++++++++++ package/systemd/Config.in | 14 ++++++++++++++ package/systemd/systemd.mk | 13 +++++++++++++ 6 files changed, 74 insertions(+) create mode 100644 package/smack/Config.in create mode 100644 package/smack/smack.mk
Signature · 1 line
1.9.0
PATCH 1/2 smack: new package.
SMACK stands for Simplified Mandatory Access Control Kernel. It is a Linux Security Module which provides a Mandatory Access Control mechanism, like SELinux, but aiming towards simplicity.
This package provides the tools to load/unload the policy from the kernel as well as a library allowing applications to interact with SMACK. The proper kernel options are also set.
--- linux/linux.mk | 4 ++++ package/Config.in | 1 + package/smack/Config.in | 28 ++++++++++++++++++++++++++++ package/smack/smack.mk | 14 ++++++++++++++ 4 files changed, 47 insertions(+) create mode 100644 package/smack/Config.in create mode 100644 package/smack/smack.mk
linux/linux.mk +4 -0
@@ -200,6 +200,10 @@ define LINUX_CONFIGURE_CMDS $(call KCONFIG_ENABLE_OPT,CONFIG_AUTOFS4_FS,$(@D)/.config) $(call KCONFIG_ENABLE_OPT,CONFIG_TMPFS_POSIX_ACL,$(@D)/.config) $(call KCONFIG_ENABLE_OPT,CONFIG_TMPFS_POSIX_XATTR,$(@D)/.config)) + $(if $(BR2_PACKAGE_SMACK), + $(call KCONFIG_ENABLE_OPT,CONFIG_SECURITY,$(@D)/.config) + $(call KCONFIG_ENABLE_OPT,CONFIG_SECURITY_SMACK,$(@D)/.config) + $(call KCONFIG_ENABLE_OPT,CONFIG_SECURITY_NETWORK,$(@D)/.config)) $(if $(BR2_LINUX_KERNEL_APPENDED_DTB), $(call KCONFIG_ENABLE_OPT,CONFIG_ARM_APPENDED_DTB,$(@D)/.config)) yes '' | $(TARGET_MAKE_ENV) $(MAKE1) $(LINUX_MAKE_FLAGS) -C $(@D) oldconfig
package/Config.in +1 -0
@@ -1104,6 +1104,7 @@ source "package/quota/Config.in" if BR2_PACKAGE_BUSYBOX_SHOW_OTHERS source "package/rsyslog/Config.in" endif +source "package/smack/Config.in" source "package/supervisor/Config.in" if BR2_PACKAGE_BUSYBOX_SHOW_OTHERS source "package/sysklogd/Config.in"
package/smack/Config.in new file +28 -0
@@ -0,0 +1,28 @@ +config BR2_PACKAGE_SMACK + bool "smack" + help + User space programs and libraries for SMACK. + + SMACK stands for Simplified Mandatory Access Control Kernel. + It is a Linux Security Module which provides a Mandatory Access + Control mechanism, aimed towards simplicity. + + This package provides a library which allows applications to work + with SMACK and tools to load/unload rules from the kernel, as well + as query the policy. + + SMACK requires the following kernel options to be enabled: + + - CONFIG_SECURITY + - CONFIG_SECURITY_SMACK + - CONFIG_SECURITY_NETWORK + + These options will be automatically enabled by Buildroot if it is + responsible for building the kernel. Otherwise, if you are building + your kernel outside of Buildroot, make sure these options are + enabled. + + To activate SMACK, do not forget to add "security=smack" to your + kernel command line. + + https://github.com/smack-team/smack
package/smack/smack.mk new file +14 -0
@@ -0,0 +1,14 @@ +################################################################################ +# +# smack +# +################################################################################ + +SMACK_VERSION = 1.0.4 +SMACK_SITE = $(call github,smack-team,smack,v$(SMACK_VERSION)) +SMACK_LICENSE = LGPLv2.1+ +SMACK_LICENSE_FILES = COPYING +SMACK_INSTALL_STAGING = YES +SMACK_AUTORECONF = YES + +$(eval $(autotools-package))
Signature · 1 line
1.9.0
PATCH 1/2 smack: new package.
Dear Eric Le Bihan,
package/smack/Config.in line 2
Quoted 8 lines · Eric Le Bihan
package/smack/Config.in new file +2
-0@@ -0,0 +1,28 @@ +config BR2_PACKAGE_SMACK + bool "smack"
Dependency on !BR2_PREFER_STATIC_LIB was missing, due to <dlfcn.h> usage. Remember to build test your packages with
http://autobuild.buildroot.org/toolchains/configs/free-electrons/bfin-linux-uclibc.config
(to test !MMU) and
http://autobuild.buildroot.org/toolchains/configs/free-electrons/bfin-uclinux.config
(to test !MMU and BR2_PREFER_STATIC_LIB).
package/smack/Config.in line 5
Quoted 3 lines
package/smack/Config.in new file +3
-0+SMACK_VERSION = 1.0.4 +SMACK_SITE = $(call github,smack-team,smack,v$(SMACK_VERSION)) +SMACK_LICENSE = LGPLv2.1+
License is actually LGPLv2.1, according to comment headers in the source code.
package/smack/Config.in line 8
Quoted 3 lines
package/smack/Config.in new file +3
-0+SMACK_LICENSE_FILES = COPYING +SMACK_INSTALL_STAGING = YES +SMACK_AUTORECONF = YES
Dependency on host-pkgconf was missing, the configure.ac script uses PKG_CHECK_MODULES.
Applied with those changes,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/2 smack: new package.
Hi!
Quoted 4 lines · Thomas Petazzoni
Dear Eric Le Bihan,
On Sun, 20 Apr 2014 20:54:03 +0200, Eric Le Bihan wrote:
Quoted 15 lines
package/smack/Config.in line 2
Quoted 8 lines
package/smack/Config.in new file +2
-0@@ -0,0 +1,28 @@ +config BR2_PACKAGE_SMACK + bool "smack"Dependency on !BR2_PREFER_STATIC_LIB was missing, due to <
dlfcn.h> usage. Remember to build test your packages with
http://autobuild.buildroot.org/toolchains/configs/free-electrons/bfin-linux-uclibc.config
(to test !MMU) and
http://autobuild.buildroot.org/toolchains/configs/free-electrons/bfin-uclinux.config
(to test !MMU andBR2_PREFER_STATIC_LIB).
Thanks for the polishing! Wouldn't it be useful to add a stanza in the docs/manual/contribute.txt about performing some compliancy tests using these two configurations before submitting new packages? Are there any other criteria that could fit compliancy tests/checklist?
Best regards,
ELB
PATCH 1/2 smack: new package.
Dear Eric Le Bihan,
Quoted 4 lines · Eric Le Bihan
Thanks for the polishing! Wouldn't it be useful to add a stanza in the
docs/manual/contribute.txtabout performing some compliancy tests using these two configurations before submitting new packages? Are there any other criteria that could fit compliancy tests/checklist?
While reviewing these packages, I was indeed thinking of writing a "package addition check list" for the manual. But I'm wondering if this wouldn't replicate quite a lot of informations already in the manual, though it's true the idea of testing with some specific toolchain configurations isn't written anywhere.
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/2 smack: new package.
Thomas Petazzoni <[email protected]> schreef:
Quoted 9 lines
Dear Eric Le Bihan,
Quoted 4 lines · Eric Le Bihan
Thanks for the polishing! Wouldn't it be useful to add a stanza in the
docs/manual/contribute.txtabout performing some compliancy tests using these two configurations before submitting new packages? Are there any other criteria that could fit compliancy tests/checklist?
Quoted 5 lines
While reviewing these packages, I was indeed thinking of writing a "package addition check list" for the manual. But I'm wondering if this wouldn't replicate quite a lot of informations already in the manual, though it's true the idea of testing with some specific toolchain configurations isn't written anywhere.
I certainly think a checklist would be a good addition to the manual. The checklist would not contain details, but only references to other parts of the manual.
Adding a list of toolchain configurations to test packages with is also on my todo list but I haven't gotten around these improvements yet...
Best regards,
Thomas
PATCH 1/2 smack: new package.
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Thomas" == Thomas De Schampheleire <[email protected]> writes:
Hi,
Quoted 6 lines
Quoted 5 lines
While reviewing these packages, I was indeed thinking of writing a "package addition check list" for the manual. But I'm wondering if this wouldn't replicate quite a lot of informations already in the manual, though it's true the idea of testing with some specific toolchain configurations isn't written anywhere.
Quoted 7 lines
I certainly think a checklist would be a good addition to the manual. The checklist would not contain details, but only references to other parts of the manual.
Adding a list of toolchain configurations to test packages with is also on my todo list but I haven't gotten around these improvements yet...
Perhaps we need something like checkpatch.pl to test a package with the various toolchain combinations?
Signature · 1 line
Bye, Peter Korsgaard
PATCH 1/2 smack: new package.
Dear Peter Korsgaard,
Quoted 10 lines · Peter Korsgaard
Quoted 9 lines
Quoted 5 lines
While reviewing these packages, I was indeed thinking of writing a "package addition check list" for the manual. But I'm wondering if this wouldn't replicate quite a lot of informations already in the manual, though it's true the idea of testing with some specific toolchain configurations isn't written anywhere.
I certainly think a checklist would be a good addition to the manual. The checklist would not contain details, but only references to other parts of the manual.
Quoted 6 lines
Quoted 3 lines
Adding a list of toolchain configurations to test packages with is also on my todo list but I haven't gotten around these improvements yet...
Perhaps we need something like checkpatch.pl to test a package with the various toolchain combinations?
That could work with the packages that don't have crazy dependencies. But as soon as the package starts depending on OpenGL or things like that, it would be more difficult I believe.
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 2/2 systemd: add SMACK support option.
In reply to Eric Le BihanA new configuration option is available in systemd menu, to enable support for SMACK.
For this feature to properly work, systemd requires attr (build dependency, also used for other features) and smack (runtime dependency).
--- package/systemd/Config.in | 14 ++++++++++++++ package/systemd/systemd.mk | 13 +++++++++++++ 2 files changed, 27 insertions(+)
package/systemd/Config.in +14 -0
@@ -105,4 +105,18 @@ config BR2_PACKAGE_SYSTEMD_COMPAT This option enables the installation of compatibility *.pc files. +config BR2_PACKAGE_SYSTEMD_SMACK_SUPPORT + bool "enable SMACK support" + select BR2_PACKAGE_ATTR + select BR2_PACKAGE_SMACK + help + Enable support for SMACK, the Simple Mandatory Access Control + Kernel, a minimal approach to Access Control implemented as a kernel + LSM. + + This feature requires a kernel >= 3.8. + + When this feature is enabled, Systemd mounts smackfs and manages + security labels for sockets. + endif
package/systemd/systemd.mk +13 -0
@@ -59,6 +59,13 @@ else SYSTEMD_CONF_OPT += --disable-acl endif +ifeq ($(BR2_PACKAGE_ATTR),y) +SYSTEMD_CONF_OPT += --enable-attr +SYSTEMD_DEPENDENCIES += attr +else +SYSTEMD_CONF_OPT += --disable-attr +endif + ifeq ($(BR2_PACKAGE_LIBGLIB2),y) SYSTEMD_CONF_OPT += --enable-gudev SYSTEMD_DEPENDENCIES += libglib2
@@ -92,6 +99,12 @@ else SYSTEMD_CONF_OPT += --disable-networkd endif +ifeq ($(BR2_PACKAGE_SYSTEMD_SMACK_SUPPORT),y) +SYSTEMD_CONF_OPT += --enable-smack +else +SYSTEMD_CONF_OPT += --disable-smack +endif + # mq_getattr needs -lrt SYSTEMD_MAKE_OPT += LIBS=-lrt SYSTEMD_MAKE_OPT += LDFLAGS+=-ldl
Signature · 1 line
1.9.0
Thomas Petazzoni
AppliedPATCH 2/2 systemd: add SMACK support option.
Dear Eric Le Bihan,
Quoted 11 lines · Eric Le Bihan
A new configuration option is available in systemd menu, to enable support for SMACK.
For this feature to properly work, systemd requires attr (build dependency, also used for other features) and smack (runtime dependency).
Signed-off-by Eric Le Bihan <[email protected]>--- package/systemd/Config.in | 14 ++++++++++++++ package/systemd/systemd.mk | 13 +++++++++++++ 2 files changed, 27 insertions(+)
Applied, thanks.
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com