[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <1445463823.6984.0.camel@nonadev.net>
Date: Wed, 21 Oct 2015 23:43:43 +0200
From: José Bollo <jobol@...adev.net>
To: linux-kernel@...r.kernel.org
Cc: casey <casey@...aufler-ca.com>
Subject: [PATCH v2 0/1] Tagging: a new Security Module
INTRODUCTION
============
Adding a feature in the kernel is not something free, it must
have some interest. I will try here to explain the reasons
why I am posting here a new bag of code.
I studied the security of Tizen 3 [1] and modestly participated
to it. Tizen 3 uses Smack as its security background. But
managing API level authorisation with Smack is nor simple
nor very efficient. The current implementation uses a component
named "cynara" [2] to record (database) the authorisation (aka
privilege) of applications. Services called can check wether
an instance of an application has or not the authorisation for
given user.
Before cynara came on the scene, I made some studies. One of it
tried to implement a keyring of authorisations using fuse [3].
The very basic idea is to securely and publicly tag processes
with authorisations that they have. The important thing here
The research based on fuse was interesting but it had big issues.
The biggest being that it can not follows application's lifecycle:
clone, execve, exit... I presented most aspects of that it at
FOSDEM 2015 [4] (thanks to Mikos).
Most of issues are merely disappearing when the keyring of
authorisations is managed as a LSM (Linux Security Module).
unfortunately, the current implementation of LSM isn't
compatible with the stacking of LSM. I made a first proposal
of the tagging system as a submodule of Smack for many
convenient reasons.
But after some mail exchanges with Casey Schaufler, I prefer
to submit it as a new Security Module that should be stacked
over some other security module. It is valuable because it is
typically independant: it could be used "on" Smack or "on"
SELinux or "on" AppArmor. So, it may help to promote effort
to allow real stacking of security components. And I think
that it is a good direction.
Nevertheless, stacking is not really possible and currently
activating tagging only works with the LSM Smack. Let me know
if other implmentation is of interest.
HOW TO ACTIVATE IT?
===================
It is a sub-module of Smack and it can be activated/deactivated in
the config using CONFIG_SECURITY_SMACK_TAGS.
WHAT IS IT DOING?
=================
Each process or thread can have a list of tags. This list is managed
by a security component of the system and is part of a chain of
trust. It can be used in many ways. The main idea is to tag processes.
The list can be empty. The list of tags is copied (this is not shared)
during 'clone' and mostly dropped during 'execve'.
By default:
- processes can NOT remove any tags for itself
- processes can NOT add any tag to itself
- processes can NOT alter (add or remove) tags of other processes
- processes mostly lose their tags during 'execve'
- processes can read tags of other processes when DAC/MAC allows it
But some rules allow authorised processes:
- to remove some or all of its tags
- to add some or any tag to itself
- to alter other processes list of tags
- to keep some or all of their tags during 'exec'
More accurate details are in the commit message.
Except for few special tags, the meaning of the tag is free.
WHAT IS THE IDEA BEHIND?
========================
An authorised process can add a tag X to itself or other process.
Later, an other process can check wether a process has or not the
tag X to adapt its behaviour.
Mechanisms here given are allowing either a centralized service
for tagging processes or a fork/exec model.
A such module can be easily used as part of a cynara like
authorisation system.
LINKS
=====
[1] https://wiki.tizen.org/wiki/Security
[2] https://wiki.tizen.org/wiki/Security/Tizen_3.X_Cynara
[3] https://github.com/jobol/keyzen
[4] https://archive.fosdem.org/2015/schedule/event/sec_enforcement/
José Bollo (1):
Tags: Adding tagging feature to security modules
fs/proc/base.c | 3 +
security/Kconfig | 2 +
security/Makefile | 2 +
security/smack/Kconfig | 9 +
security/smack/smack.h | 7 +
security/smack/smack_lsm.c | 50 ++++
security/tags/Kconfig | 8 +
security/tags/Makefile | 6 +
security/tags/tags.c | 731
+++++++++++++++++++++++++++++++++++++++++++++
security/tags/tags.h | 39 +++
10 files changed, 857 insertions(+)
create mode 100644 security/tags/Kconfig
create mode 100644 security/tags/Makefile
create mode 100644 security/tags/tags.c
create mode 100644 security/tags/tags.h
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists