Re: [PATCH 1/2] ext4: use XATTR_*_PREFIX_LEN instead sizeof(...)

[José Bollo]

I prefer the use of sizeof that can't be faked even by error but why not

Le dimanche 03 janvier 2016 à 20:56 +0100, Toralf Förster a écrit :
> use the definition in include/uapi/linux/xattr.h
> 
> Signed-off-by: Toralf Förster 
> ---
>  fs/ext4/xattr_security.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/ext4/xattr_security.c b/fs/ext4/xattr_security.c
> index 36f4c1a..1a3d629 100644
> --- a/fs/ext4/xattr_security.c
> +++ b/fs/ext4/xattr_security.c
> @@ -16,7 +16,7 @@ ext4_xattr_security_list(const struct xattr_handler 
> *handler,
>struct dentry *dentry, char *list, size_t list_size,
>const char *name, size_t name_len)
>  {
> - const size_t prefix_len = sizeof(XATTR_SECURITY_PREFIX)-1;
> + const size_t prefix_len = XATTR_SECURITY_PREFIX_LEN;
>   const size_t total_len = prefix_len + name_len + 1;
>  
> 


--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/1] Tags: Adding tagging feature to security modules

[José Bollo]

The Tags security module allows to attach tags to processes.
Tags are accessed through the new files /proc/PID/attr/tags
and /proc/PID/tasks/TID/attr/tags below named "tag file".

Reading a tag file returns all the tags attached to the process
(or thread). The tags are listed one per line, each followed by
exactly one new-line character ('\n').

Writing a tag file allows under condition to change the tags of a
process. When writting the file, it acts like a protocol accepting
lines. The accepted lines are:

 - empty: "\n"

only a new-line

 - comment: "#...anything...\n"

 a sharp followed by anything and a new-line

 - remove all tags: "-\n"

 a minus followed by a new-line

 - remove one tag: "-TAGNAME\n"

 a minus followed by the name of the tag and a new-line

 - add one tag: "+TAGNAME\n"

 a plus followed by the name of the tag and a new-line

 - query one tag: "?TAGNAME\n"

 a question mark followed by the name of the tag and a new-line

Be aware that the current implementation doesn't trim any extra
characters like spaces or tabs.

Names of tags can have any ASCII printable character (in the
ranges [33...126] that is from '!' to '~'. The minimum length
of a tag's name is 1 and the maximum length is 1000 bytes.

It exist 7 special tags. Their names are:
 - tags:add
 - tags:sub
 - tags:keep
 - tags:add-all
 - tags:sub-all
 - tags:keep-all
 - tags:set-others

All other tags prefixed by "tags:" are reserved and can not be used.

Normally a process can not remove tags from itself. A process can
remove a tag from itself only if one or more of the following
conditions is true:
 - the process has not the tag (it is not an error)
 - the process has the tag "tags:sub" and the tag to remove
   is not a special tag
 - the process has the tag "tags:sub-all"
 - the process is a kernel's thread
 - the process has the capability CAP_MAC_ADMIN

Normally a process can not add tags to itself. A process can add
a tag to itself only if one or more of the following conditions
is true:
 - the process already has the tag (it is not an error)
 - the process has the tag "tags:add" and the tag to add
   is not a special tag
 - the process has the tag "tags:add-all"
 - the process is a kernel's thread
 - the process has the capability CAP_MAC_ADMIN

Even if a process has the right to add tags, it can be canceled
(ECANCELED) if the count of tag reached is too high. The current
limit is 1000. This limit is global to the kernel, not by process.

Normally a process can not add or remove tags of other processes.
But it can do that if it has the tag "tags:set-others".

Tags are copied to the children processes during 'clone'.

During execution of 'execve', the following rules apply:
 - processes having the tag "tags:keep-all" keep all there tags;
 - otherwise, processes having "tags:keep" keep the tags that are
   not specials;
 - otherwise, processes only keep tags that are prefixed with the
   character * (star).

Because changes only occur through tag files accesses, the
notifications might be available to any possible observer.

Signed-off-by: José Bollo <jo...@nonadev.net>
---
 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

diff --git a/fs/proc/base.c b/fs/proc/base.c
index b25eee4..b1a47daa 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -2406,6 +2406,9 @@ static const struct pid_entry attr_dir_stuff[] = {
REG("fscreate",   S_IRUGO|S_IWUGO, proc_pid_attr_operations),
REG("keycreate",  S_IRUGO|S_IWUGO, proc_pid_attr_operations),
REG("sockcreate", S_IRUGO|S_IWUGO, proc_pid_attr_operations),
+#ifdef CONFIG_SECURITY_TAGS
+   REG("tags",   S_IRUGO|S_IWUGO, proc_pid_attr_operations),
+#endif
 };
 
 static int proc_attr_dir_readdir(struct file *file, struct dir_context
*ctx)
diff --git a/security/Kconfig b/security/Kconfig
index e452378..2e628d2 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -118,6 +118,8 @@ config LSM_MMAP_MIN_ADDR
  this low address space will need the permission specific to the
  systems running LSM.
 
+source security/tags/Kconfig
+
 source security/selinux/Kconfig
 source security/smack/Kconfig
 source security/tomoyo/Kconfig
diff --git a/security/Makefile b/security/Makefi

[PATCH v2 0/1] Tagging: a new Security Module

[José Bollo]

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



--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v1 0/1] Smack: adding Smack-Tags subsystem

[José Bollo]

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].
This was an interesting research but it had big issues.
The biggest being that it can not follows application's lifecycle:
clone, exec, exit...

This issues are merely disappearing when the keyring of
authorisations is managed by a LSM (Linux Security Module).
I submit here this "sub"-module of Smack.

I used not the word of "authorisation" but just the word
of "tag". The reason is that the submodule can be used for
any purpose.

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 receive a list of tags. This list can
be empty. This tags are copied (this is not shared) during 'clone'
and mostly kept during 'exec'.

By default:
 - processes can NOT remove any tags for itself
 - processes can NOT add any tag to itself
 - processes can NOT alter the tags of other processes
 - processes lose their tags during 'execve'
 - processes can read tags of other processes when DAC/MAC allows it

But some rules allow:
 - authorised processes can remove tags
 - authorised processes can add tags
 - authorised processes can alter other processes tags
 - authorised processes can keep their tags during 'exec'

More accurate details are in the commit message.

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

José Bollo (1):
  Smack: adding Smack-Tags subsystem

 fs/proc/base.c  |   3 +
 security/smack/Kconfig  |   8 +
 security/smack/Makefile |   1 +
 security/smack/smack.h  |   7 +
 security/smack/smack_lsm.c  |  39 +++
 security/smack/smack_tags.c | 641

 security/smack/smack_tags.h |  40 +++
 7 files changed, 739 insertions(+)
 create mode 100644 security/smack/smack_tags.c
 create mode 100644 security/smack/smack_tags.h

-- 
2.1.4



--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Smack: Minor initialisation improvement

[José Bollo]

This change has two goals:
 - delay the setting of 'smack_enabled' until
   it will be really effective
 - ensure that smackfs is valid only if 'smack_enabled'
   is set (it is already the case in smack_netfilter.c)

Signed-off-by: José Bollo <jose.bo...@iot.bzh>
---
 security/smack/smack_lsm.c | 4 ++--
 security/smack/smackfs.c   | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index 996c889..dd0f0a6 100644
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -4708,8 +4708,6 @@ static __init int smack_init(void)
if (!security_module_enable("smack"))
return 0;
 
-   smack_enabled = 1;
-
smack_inode_cache = KMEM_CACHE(inode_smack, 0);
if (!smack_inode_cache)
return -ENOMEM;
@@ -4721,6 +4719,8 @@ static __init int smack_init(void)
return -ENOMEM;
}
 
+   smack_enabled = 1;
+
pr_info("Smack:  Initializing.\n");
 #ifdef CONFIG_SECURITY_SMACK_NETFILTER
pr_info("Smack:  Netfilter enabled.\n");
diff --git a/security/smack/smackfs.c b/security/smack/smackfs.c
index c20b154..d2bb5ee 100644
--- a/security/smack/smackfs.c
+++ b/security/smack/smackfs.c
@@ -2892,7 +2892,7 @@ static int __init init_smk_fs(void)
int err;
int rc;
 
-   if (!security_module_enable("smack"))
+   if (smack_enabled == 0)
return 0;
 
err = smk_init_sysfs();
-- 
2.1.4




--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Smack: Fix wrong copy size

[José Bollo]

The function strncpy was copying an extra character
when i == len (what is possible via revoke interface).

Change-Id: Ic7452da05773e620a1d7bbc55e859c25a86c65f6
Signed-off-by: José Bollo <jose.bo...@open.eurogiciel.org>
Signed-off-by: Stephane Desneux <stephane.desn...@iot.bzh>
---
 security/smack/smack_access.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/security/smack/smack_access.c
b/security/smack/smack_access.c
index c062e94..930e548 100644
--- a/security/smack/smack_access.c
+++ b/security/smack/smack_access.c
@@ -432,7 +432,7 @@ char *smk_parse_smack(const char *string, int len)
 
smack = kzalloc(i + 1, GFP_KERNEL);
if (smack != NULL) {
-   strncpy(smack, string, i + 1);
+   strncpy(smack, string, i);
smack[i] = '\0';
}
return smack;
-- 
1.9.1



--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html