Skip to contentSkip to conversation

SMACK: mandatory access control

PATCH New Eric Le Bihan 4 participants 10 messages Apr 20, 2014 – Jun 8, 2014

lore
Share & tools
lore
#0 lore raw

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
#1 lore raw

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
index e270705..bd3f2ac 100644
@@ -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
index 44c35ea..323596e 100644
@@ -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
new file mode 100644
index 0000000..971b79a
@@ -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
new file mode 100644
index 0000000..41f71a4
@@ -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
#2 lore raw

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
new file mode 100644
index 0000000..971b79a
@@ -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
#3 lore raw

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
new file mode 100644
index 0000000..971b79a
@@ -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).

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

#4 lore raw

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.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?

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
#5 lore raw

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.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?

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

#6 lore raw

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
#7 lore raw

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
#8 lore raw

PATCH 2/2 systemd: add SMACK support option.

In reply to 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).

---
 package/systemd/Config.in  | 14 ++++++++++++++
 package/systemd/systemd.mk | 13 +++++++++++++
 2 files changed, 27 insertions(+)
package/systemd/Config.in +14 -0
index f10637a..0c8ecd8 100644
@@ -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
index f7661ab..0dfd0c0 100644
@@ -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
#9 lore raw

PATCH 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).

---
 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