* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-11 19:55 [RFC][PATCH] selinux: enable authoritative granting of capabilities Stephen Smalley
@ 2007-06-11 20:39 ` James Morris
2007-06-11 20:43 ` Serge E. Hallyn
` (3 subsequent siblings)
4 siblings, 0 replies; 60+ messages in thread
From: James Morris @ 2007-06-11 20:39 UTC (permalink / raw)
To: Stephen Smalley; +Cc: selinux, Eric Paris, Serge E. Hallyn
On Mon, 11 Jun 2007, Stephen Smalley wrote:
> Extend SELinux to allow capabilities to be granted authoritatively.
> Introduces a new cap_override access vector to indicate when the
> secondary module (i.e. capability or dummy) check should be skipped.
> Handle the new class gracefully even if the policy does not yet have
> it defined.
Looks good to me.
>
> ---
>
> security/selinux/hooks.c | 12 +++++++---
> security/selinux/include/av_perm_to_string.h | 31 +++++++++++++++++++++++++++
> security/selinux/include/av_permissions.h | 31 +++++++++++++++++++++++++++
> security/selinux/include/class_to_string.h | 1
> security/selinux/include/flask.h | 1
> security/selinux/ss/services.c | 11 +++------
> 6 files changed, 77 insertions(+), 10 deletions(-)
>
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 4b0ecfd..9b200ef 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -1419,11 +1419,17 @@ static void selinux_capset_set(struct task_struct *target, kernel_cap_t *effecti
>
> static int selinux_capable(struct task_struct *tsk, int cap)
> {
> + struct task_security_struct *tsec = tsk->security;
> + u32 sid = tsec->sid;
> int rc;
>
> - rc = secondary_ops->capable(tsk, cap);
> - if (rc)
> - return rc;
> + rc = avc_has_perm_noaudit(sid, sid, SECCLASS_CAP_OVERRIDE,
> + CAP_TO_MASK(cap), 0, NULL);
> + if (rc) {
> + rc = secondary_ops->capable(tsk, cap);
> + if (rc)
> + return rc;
> + }
>
> return task_has_capability(tsk,cap);
> }
> diff --git a/security/selinux/include/av_inherit.h b/security/selinux/include/av_inherit.h
> diff --git a/security/selinux/include/av_perm_to_string.h b/security/selinux/include/av_perm_to_string.h
> index 049bf69..fc19a4d 100644
> --- a/security/selinux/include/av_perm_to_string.h
> +++ b/security/selinux/include/av_perm_to_string.h
> @@ -159,3 +159,34 @@
> S_(SECCLASS_DCCP_SOCKET, DCCP_SOCKET__NODE_BIND, "node_bind")
> S_(SECCLASS_DCCP_SOCKET, DCCP_SOCKET__NAME_CONNECT, "name_connect")
> S_(SECCLASS_MEMPROTECT, MEMPROTECT__MMAP_ZERO, "mmap_zero")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__CHOWN, "chown")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__DAC_OVERRIDE, "dac_override")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__DAC_READ_SEARCH, "dac_read_search")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__FOWNER, "fowner")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__FSETID, "fsetid")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__KILL, "kill")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__SETGID, "setgid")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__SETUID, "setuid")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__SETPCAP, "setpcap")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__LINUX_IMMUTABLE, "linux_immutable")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__NET_BIND_SERVICE, "net_bind_service")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__NET_BROADCAST, "net_broadcast")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__NET_ADMIN, "net_admin")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__NET_RAW, "net_raw")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__IPC_LOCK, "ipc_lock")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__IPC_OWNER, "ipc_owner")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__SYS_MODULE, "sys_module")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__SYS_RAWIO, "sys_rawio")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__SYS_CHROOT, "sys_chroot")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__SYS_PTRACE, "sys_ptrace")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__SYS_PACCT, "sys_pacct")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__SYS_ADMIN, "sys_admin")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__SYS_BOOT, "sys_boot")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__SYS_NICE, "sys_nice")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__SYS_RESOURCE, "sys_resource")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__SYS_TIME, "sys_time")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__SYS_TTY_CONFIG, "sys_tty_config")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__MKNOD, "mknod")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__LEASE, "lease")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__AUDIT_WRITE, "audit_write")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__AUDIT_CONTROL, "audit_control")
> diff --git a/security/selinux/include/av_permissions.h b/security/selinux/include/av_permissions.h
> index eda89a2..b5f01a1 100644
> --- a/security/selinux/include/av_permissions.h
> +++ b/security/selinux/include/av_permissions.h
> @@ -824,3 +824,34 @@
> #define DCCP_SOCKET__NODE_BIND 0x00400000UL
> #define DCCP_SOCKET__NAME_CONNECT 0x00800000UL
> #define MEMPROTECT__MMAP_ZERO 0x00000001UL
> +#define CAP_OVERRIDE__CHOWN 0x00000001UL
> +#define CAP_OVERRIDE__DAC_OVERRIDE 0x00000002UL
> +#define CAP_OVERRIDE__DAC_READ_SEARCH 0x00000004UL
> +#define CAP_OVERRIDE__FOWNER 0x00000008UL
> +#define CAP_OVERRIDE__FSETID 0x00000010UL
> +#define CAP_OVERRIDE__KILL 0x00000020UL
> +#define CAP_OVERRIDE__SETGID 0x00000040UL
> +#define CAP_OVERRIDE__SETUID 0x00000080UL
> +#define CAP_OVERRIDE__SETPCAP 0x00000100UL
> +#define CAP_OVERRIDE__LINUX_IMMUTABLE 0x00000200UL
> +#define CAP_OVERRIDE__NET_BIND_SERVICE 0x00000400UL
> +#define CAP_OVERRIDE__NET_BROADCAST 0x00000800UL
> +#define CAP_OVERRIDE__NET_ADMIN 0x00001000UL
> +#define CAP_OVERRIDE__NET_RAW 0x00002000UL
> +#define CAP_OVERRIDE__IPC_LOCK 0x00004000UL
> +#define CAP_OVERRIDE__IPC_OWNER 0x00008000UL
> +#define CAP_OVERRIDE__SYS_MODULE 0x00010000UL
> +#define CAP_OVERRIDE__SYS_RAWIO 0x00020000UL
> +#define CAP_OVERRIDE__SYS_CHROOT 0x00040000UL
> +#define CAP_OVERRIDE__SYS_PTRACE 0x00080000UL
> +#define CAP_OVERRIDE__SYS_PACCT 0x00100000UL
> +#define CAP_OVERRIDE__SYS_ADMIN 0x00200000UL
> +#define CAP_OVERRIDE__SYS_BOOT 0x00400000UL
> +#define CAP_OVERRIDE__SYS_NICE 0x00800000UL
> +#define CAP_OVERRIDE__SYS_RESOURCE 0x01000000UL
> +#define CAP_OVERRIDE__SYS_TIME 0x02000000UL
> +#define CAP_OVERRIDE__SYS_TTY_CONFIG 0x04000000UL
> +#define CAP_OVERRIDE__MKNOD 0x08000000UL
> +#define CAP_OVERRIDE__LEASE 0x10000000UL
> +#define CAP_OVERRIDE__AUDIT_WRITE 0x20000000UL
> +#define CAP_OVERRIDE__AUDIT_CONTROL 0x40000000UL
> diff --git a/security/selinux/include/class_to_string.h b/security/selinux/include/class_to_string.h
> index e77de0e..442a188 100644
> --- a/security/selinux/include/class_to_string.h
> +++ b/security/selinux/include/class_to_string.h
> @@ -64,3 +64,4 @@
> S_(NULL)
> S_("dccp_socket")
> S_("memprotect")
> + S_("cap_override")
> diff --git a/security/selinux/include/common_perm_to_string.h b/security/selinux/include/common_perm_to_string.h
> diff --git a/security/selinux/include/flask.h b/security/selinux/include/flask.h
> index a9c2b20..ab1b861 100644
> --- a/security/selinux/include/flask.h
> +++ b/security/selinux/include/flask.h
> @@ -50,6 +50,7 @@
> #define SECCLASS_KEY 58
> #define SECCLASS_DCCP_SOCKET 60
> #define SECCLASS_MEMPROTECT 61
> +#define SECCLASS_CAP_OVERRIDE 62
>
> /*
> * Security identifier indices for initial entities
> diff --git a/security/selinux/include/initial_sid_to_string.h b/security/selinux/include/initial_sid_to_string.h
> diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
> index b5f017f..d16c809 100644
> --- a/security/selinux/ss/services.c
> +++ b/security/selinux/ss/services.c
> @@ -305,13 +305,6 @@ static int context_struct_compute_av(struct context *scontext,
> tclass <= SECCLASS_NETLINK_DNRT_SOCKET)
> tclass = SECCLASS_NETLINK_SOCKET;
>
> - if (!tclass || tclass > policydb.p_classes.nprim) {
> - printk(KERN_ERR "security_compute_av: unrecognized class %d\n",
> - tclass);
> - return -EINVAL;
> - }
> - tclass_datum = policydb.class_val_to_struct[tclass - 1];
> -
> /*
> * Initialize the access vectors to the default values.
> */
> @@ -321,6 +314,9 @@ static int context_struct_compute_av(struct context *scontext,
> avd->auditdeny = 0xffffffff;
> avd->seqno = latest_granting;
>
> + if (!tclass || tclass > policydb.p_classes.nprim)
> + return 0;
> +
> /*
> * If a specific type enforcement rule was defined for
> * this permission check, then use it.
> @@ -358,6 +354,7 @@ static int context_struct_compute_av(struct context *scontext,
> * Remove any permissions prohibited by a constraint (this includes
> * the MLS policy).
> */
> + tclass_datum = policydb.class_val_to_struct[tclass - 1];
> constraint = tclass_datum->constraints;
> while (constraint) {
> if ((constraint->permissions & (avd->allowed)) &&
>
>
--
James Morris
<jmorris@namei.org>
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-11 19:55 [RFC][PATCH] selinux: enable authoritative granting of capabilities Stephen Smalley
2007-06-11 20:39 ` James Morris
@ 2007-06-11 20:43 ` Serge E. Hallyn
2007-06-11 21:43 ` Casey Schaufler
2007-06-12 9:27 ` Russell Coker
2007-06-12 12:50 ` Stephen Smalley
` (2 subsequent siblings)
4 siblings, 2 replies; 60+ messages in thread
From: Serge E. Hallyn @ 2007-06-11 20:43 UTC (permalink / raw)
To: Stephen Smalley; +Cc: selinux, James Morris, Eric Paris, Serge E. Hallyn
Quoting Stephen Smalley (sds@tycho.nsa.gov):
> Extend SELinux to allow capabilities to be granted authoritatively.
> Introduces a new cap_override access vector to indicate when the
> secondary module (i.e. capability or dummy) check should be skipped.
> Handle the new class gracefully even if the policy does not yet have
> it defined.
Cool.
If we decide to have this take the place of the file capabilities i
guess we're all set, but if both are going upstream, do you think
CONFIG_SECURITY_FILE_CAPABILITIES and selinux should be mutually
exclusive?
thanks,
-serge
> ---
>
> security/selinux/hooks.c | 12 +++++++---
> security/selinux/include/av_perm_to_string.h | 31 +++++++++++++++++++++++++++
> security/selinux/include/av_permissions.h | 31 +++++++++++++++++++++++++++
> security/selinux/include/class_to_string.h | 1
> security/selinux/include/flask.h | 1
> security/selinux/ss/services.c | 11 +++------
> 6 files changed, 77 insertions(+), 10 deletions(-)
>
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 4b0ecfd..9b200ef 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -1419,11 +1419,17 @@ static void selinux_capset_set(struct task_struct *target, kernel_cap_t *effecti
>
> static int selinux_capable(struct task_struct *tsk, int cap)
> {
> + struct task_security_struct *tsec = tsk->security;
> + u32 sid = tsec->sid;
> int rc;
>
> - rc = secondary_ops->capable(tsk, cap);
> - if (rc)
> - return rc;
> + rc = avc_has_perm_noaudit(sid, sid, SECCLASS_CAP_OVERRIDE,
> + CAP_TO_MASK(cap), 0, NULL);
> + if (rc) {
> + rc = secondary_ops->capable(tsk, cap);
> + if (rc)
> + return rc;
> + }
>
> return task_has_capability(tsk,cap);
> }
> diff --git a/security/selinux/include/av_inherit.h b/security/selinux/include/av_inherit.h
> diff --git a/security/selinux/include/av_perm_to_string.h b/security/selinux/include/av_perm_to_string.h
> index 049bf69..fc19a4d 100644
> --- a/security/selinux/include/av_perm_to_string.h
> +++ b/security/selinux/include/av_perm_to_string.h
> @@ -159,3 +159,34 @@
> S_(SECCLASS_DCCP_SOCKET, DCCP_SOCKET__NODE_BIND, "node_bind")
> S_(SECCLASS_DCCP_SOCKET, DCCP_SOCKET__NAME_CONNECT, "name_connect")
> S_(SECCLASS_MEMPROTECT, MEMPROTECT__MMAP_ZERO, "mmap_zero")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__CHOWN, "chown")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__DAC_OVERRIDE, "dac_override")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__DAC_READ_SEARCH, "dac_read_search")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__FOWNER, "fowner")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__FSETID, "fsetid")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__KILL, "kill")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__SETGID, "setgid")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__SETUID, "setuid")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__SETPCAP, "setpcap")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__LINUX_IMMUTABLE, "linux_immutable")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__NET_BIND_SERVICE, "net_bind_service")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__NET_BROADCAST, "net_broadcast")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__NET_ADMIN, "net_admin")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__NET_RAW, "net_raw")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__IPC_LOCK, "ipc_lock")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__IPC_OWNER, "ipc_owner")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__SYS_MODULE, "sys_module")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__SYS_RAWIO, "sys_rawio")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__SYS_CHROOT, "sys_chroot")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__SYS_PTRACE, "sys_ptrace")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__SYS_PACCT, "sys_pacct")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__SYS_ADMIN, "sys_admin")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__SYS_BOOT, "sys_boot")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__SYS_NICE, "sys_nice")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__SYS_RESOURCE, "sys_resource")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__SYS_TIME, "sys_time")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__SYS_TTY_CONFIG, "sys_tty_config")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__MKNOD, "mknod")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__LEASE, "lease")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__AUDIT_WRITE, "audit_write")
> + S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__AUDIT_CONTROL, "audit_control")
> diff --git a/security/selinux/include/av_permissions.h b/security/selinux/include/av_permissions.h
> index eda89a2..b5f01a1 100644
> --- a/security/selinux/include/av_permissions.h
> +++ b/security/selinux/include/av_permissions.h
> @@ -824,3 +824,34 @@
> #define DCCP_SOCKET__NODE_BIND 0x00400000UL
> #define DCCP_SOCKET__NAME_CONNECT 0x00800000UL
> #define MEMPROTECT__MMAP_ZERO 0x00000001UL
> +#define CAP_OVERRIDE__CHOWN 0x00000001UL
> +#define CAP_OVERRIDE__DAC_OVERRIDE 0x00000002UL
> +#define CAP_OVERRIDE__DAC_READ_SEARCH 0x00000004UL
> +#define CAP_OVERRIDE__FOWNER 0x00000008UL
> +#define CAP_OVERRIDE__FSETID 0x00000010UL
> +#define CAP_OVERRIDE__KILL 0x00000020UL
> +#define CAP_OVERRIDE__SETGID 0x00000040UL
> +#define CAP_OVERRIDE__SETUID 0x00000080UL
> +#define CAP_OVERRIDE__SETPCAP 0x00000100UL
> +#define CAP_OVERRIDE__LINUX_IMMUTABLE 0x00000200UL
> +#define CAP_OVERRIDE__NET_BIND_SERVICE 0x00000400UL
> +#define CAP_OVERRIDE__NET_BROADCAST 0x00000800UL
> +#define CAP_OVERRIDE__NET_ADMIN 0x00001000UL
> +#define CAP_OVERRIDE__NET_RAW 0x00002000UL
> +#define CAP_OVERRIDE__IPC_LOCK 0x00004000UL
> +#define CAP_OVERRIDE__IPC_OWNER 0x00008000UL
> +#define CAP_OVERRIDE__SYS_MODULE 0x00010000UL
> +#define CAP_OVERRIDE__SYS_RAWIO 0x00020000UL
> +#define CAP_OVERRIDE__SYS_CHROOT 0x00040000UL
> +#define CAP_OVERRIDE__SYS_PTRACE 0x00080000UL
> +#define CAP_OVERRIDE__SYS_PACCT 0x00100000UL
> +#define CAP_OVERRIDE__SYS_ADMIN 0x00200000UL
> +#define CAP_OVERRIDE__SYS_BOOT 0x00400000UL
> +#define CAP_OVERRIDE__SYS_NICE 0x00800000UL
> +#define CAP_OVERRIDE__SYS_RESOURCE 0x01000000UL
> +#define CAP_OVERRIDE__SYS_TIME 0x02000000UL
> +#define CAP_OVERRIDE__SYS_TTY_CONFIG 0x04000000UL
> +#define CAP_OVERRIDE__MKNOD 0x08000000UL
> +#define CAP_OVERRIDE__LEASE 0x10000000UL
> +#define CAP_OVERRIDE__AUDIT_WRITE 0x20000000UL
> +#define CAP_OVERRIDE__AUDIT_CONTROL 0x40000000UL
> diff --git a/security/selinux/include/class_to_string.h b/security/selinux/include/class_to_string.h
> index e77de0e..442a188 100644
> --- a/security/selinux/include/class_to_string.h
> +++ b/security/selinux/include/class_to_string.h
> @@ -64,3 +64,4 @@
> S_(NULL)
> S_("dccp_socket")
> S_("memprotect")
> + S_("cap_override")
> diff --git a/security/selinux/include/common_perm_to_string.h b/security/selinux/include/common_perm_to_string.h
> diff --git a/security/selinux/include/flask.h b/security/selinux/include/flask.h
> index a9c2b20..ab1b861 100644
> --- a/security/selinux/include/flask.h
> +++ b/security/selinux/include/flask.h
> @@ -50,6 +50,7 @@
> #define SECCLASS_KEY 58
> #define SECCLASS_DCCP_SOCKET 60
> #define SECCLASS_MEMPROTECT 61
> +#define SECCLASS_CAP_OVERRIDE 62
>
> /*
> * Security identifier indices for initial entities
> diff --git a/security/selinux/include/initial_sid_to_string.h b/security/selinux/include/initial_sid_to_string.h
> diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
> index b5f017f..d16c809 100644
> --- a/security/selinux/ss/services.c
> +++ b/security/selinux/ss/services.c
> @@ -305,13 +305,6 @@ static int context_struct_compute_av(struct context *scontext,
> tclass <= SECCLASS_NETLINK_DNRT_SOCKET)
> tclass = SECCLASS_NETLINK_SOCKET;
>
> - if (!tclass || tclass > policydb.p_classes.nprim) {
> - printk(KERN_ERR "security_compute_av: unrecognized class %d\n",
> - tclass);
> - return -EINVAL;
> - }
> - tclass_datum = policydb.class_val_to_struct[tclass - 1];
> -
> /*
> * Initialize the access vectors to the default values.
> */
> @@ -321,6 +314,9 @@ static int context_struct_compute_av(struct context *scontext,
> avd->auditdeny = 0xffffffff;
> avd->seqno = latest_granting;
>
> + if (!tclass || tclass > policydb.p_classes.nprim)
> + return 0;
> +
> /*
> * If a specific type enforcement rule was defined for
> * this permission check, then use it.
> @@ -358,6 +354,7 @@ static int context_struct_compute_av(struct context *scontext,
> * Remove any permissions prohibited by a constraint (this includes
> * the MLS policy).
> */
> + tclass_datum = policydb.class_val_to_struct[tclass - 1];
> constraint = tclass_datum->constraints;
> while (constraint) {
> if ((constraint->permissions & (avd->allowed)) &&
>
> --
> Stephen Smalley
> National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-11 20:43 ` Serge E. Hallyn
@ 2007-06-11 21:43 ` Casey Schaufler
2007-06-11 22:20 ` James Morris
` (2 more replies)
2007-06-12 9:27 ` Russell Coker
1 sibling, 3 replies; 60+ messages in thread
From: Casey Schaufler @ 2007-06-11 21:43 UTC (permalink / raw)
To: Serge E. Hallyn, Stephen Smalley
Cc: selinux, James Morris, Eric Paris, Serge E. Hallyn
--- "Serge E. Hallyn" <serue@us.ibm.com> wrote:
> Quoting Stephen Smalley (sds@tycho.nsa.gov):
> > Extend SELinux to allow capabilities to be granted authoritatively.
> > Introduces a new cap_override access vector to indicate when the
> > secondary module (i.e. capability or dummy) check should be skipped.
> > Handle the new class gracefully even if the policy does not yet have
> > it defined.
>
> Cool.
>
> If we decide to have this take the place of the file capabilities i
> guess we're all set, but if both are going upstream, do you think
> CONFIG_SECURITY_FILE_CAPABILITIES and selinux should be mutually
> exclusive?
We're already living in a non-stacking LSM environment, so whatever
SELinux wants to do with capabilities is Stephen's affair, I suppose.
I assume that this is in preparation for file based capabilities
and dealing with interactions with them. My only concern is that you
seem to be sneaking around the "additional restrictions" LSM model,
with the justification being that the bit you're taking authority over
is also an LSM module. I am not convinced that you're completely
within the spirit of the thing, although I would hesitate to accuse
you of not playing nicely quite yet.
Casey Schaufler
casey@schaufler-ca.com
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-11 21:43 ` Casey Schaufler
@ 2007-06-11 22:20 ` James Morris
2007-06-12 0:00 ` Casey Schaufler
2007-06-11 22:24 ` Serge E. Hallyn
2007-06-12 11:31 ` Stephen Smalley
2 siblings, 1 reply; 60+ messages in thread
From: James Morris @ 2007-06-11 22:20 UTC (permalink / raw)
To: Casey Schaufler; +Cc: Serge E. Hallyn, Stephen Smalley, selinux, Eric Paris
On Mon, 11 Jun 2007, Casey Schaufler wrote:
> and dealing with interactions with them. My only concern is that you
> seem to be sneaking around the "additional restrictions" LSM model,
> with the justification being that the bit you're taking authority over
> is also an LSM module.
SELinux itself stacks capabilities as a secondary module, and thus already
has full authority over the LSM in the coarse sense of whether it is
actually loaded or not.
- James
--
James Morris
<jmorris@namei.org>
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-11 22:20 ` James Morris
@ 2007-06-12 0:00 ` Casey Schaufler
2007-06-12 11:46 ` Stephen Smalley
0 siblings, 1 reply; 60+ messages in thread
From: Casey Schaufler @ 2007-06-12 0:00 UTC (permalink / raw)
To: James Morris, Casey Schaufler
Cc: Serge E. Hallyn, Stephen Smalley, selinux, Eric Paris
--- James Morris <jmorris@namei.org> wrote:
> On Mon, 11 Jun 2007, Casey Schaufler wrote:
>
> > and dealing with interactions with them. My only concern is that you
> > seem to be sneaking around the "additional restrictions" LSM model,
> > with the justification being that the bit you're taking authority over
> > is also an LSM module.
>
> SELinux itself stacks capabilities as a secondary module, and thus already
> has full authority over the LSM in the coarse sense of whether it is
> actually loaded or not.
You betcha. To date it has always respected the denials generated by
the mechanism, however. If the leading advanced security scheme (SELinux)
asserts authority over another scheme (capabilities) such that the
latter is perceived to behave differently when the system has been
"secured" (even though it is in fact SELinux that is changing its
behavior) the untrained observer may reasonably assume that the "new"
behavior is more secure than the old even though it may actually be
less restrictive.
I would prefer that the pretext of "stacking" with capabilities be
abandoned if the plan is to ignore the "additional restrictions"
rule. As you say, SELinux already has full authority over
capabilities by virtue of linkage and the lack of real stacking.
Casey Schaufler
casey@schaufler-ca.com
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-12 0:00 ` Casey Schaufler
@ 2007-06-12 11:46 ` Stephen Smalley
0 siblings, 0 replies; 60+ messages in thread
From: Stephen Smalley @ 2007-06-12 11:46 UTC (permalink / raw)
To: casey; +Cc: James Morris, Serge E. Hallyn, selinux, Eric Paris
On Mon, 2007-06-11 at 17:00 -0700, Casey Schaufler wrote:
> --- James Morris <jmorris@namei.org> wrote:
>
> > On Mon, 11 Jun 2007, Casey Schaufler wrote:
> >
> > > and dealing with interactions with them. My only concern is that you
> > > seem to be sneaking around the "additional restrictions" LSM model,
> > > with the justification being that the bit you're taking authority over
> > > is also an LSM module.
> >
> > SELinux itself stacks capabilities as a secondary module, and thus already
> > has full authority over the LSM in the coarse sense of whether it is
> > actually loaded or not.
>
> You betcha. To date it has always respected the denials generated by
> the mechanism, however. If the leading advanced security scheme (SELinux)
> asserts authority over another scheme (capabilities) such that the
> latter is perceived to behave differently when the system has been
> "secured" (even though it is in fact SELinux that is changing its
> behavior) the untrained observer may reasonably assume that the "new"
> behavior is more secure than the old even though it may actually be
> less restrictive.
>
> I would prefer that the pretext of "stacking" with capabilities be
> abandoned if the plan is to ignore the "additional restrictions"
> rule. As you say, SELinux already has full authority over
> capabilities by virtue of linkage and the lack of real stacking.
We already plan to remove the secondary module support from selinux and
replace it with direct calls to the cap_ functions where we want them,
using the commoncap code as a library rather than a secondary module.
The only delicate point there is making sure that the runtime disable
support for selinux still works (falls back to capabilities
when /etc/selinux/config says SELINUX=disabled).
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-11 21:43 ` Casey Schaufler
2007-06-11 22:20 ` James Morris
@ 2007-06-11 22:24 ` Serge E. Hallyn
2007-06-12 9:20 ` Russell Coker
2007-06-12 11:43 ` Stephen Smalley
2007-06-12 11:31 ` Stephen Smalley
2 siblings, 2 replies; 60+ messages in thread
From: Serge E. Hallyn @ 2007-06-11 22:24 UTC (permalink / raw)
To: Casey Schaufler
Cc: Serge E. Hallyn, Stephen Smalley, selinux, James Morris,
Eric Paris
Quoting Casey Schaufler (casey@schaufler-ca.com):
>
> --- "Serge E. Hallyn" <serue@us.ibm.com> wrote:
>
> > Quoting Stephen Smalley (sds@tycho.nsa.gov):
> > > Extend SELinux to allow capabilities to be granted authoritatively.
> > > Introduces a new cap_override access vector to indicate when the
> > > secondary module (i.e. capability or dummy) check should be skipped.
> > > Handle the new class gracefully even if the policy does not yet have
> > > it defined.
> >
> > Cool.
> >
> > If we decide to have this take the place of the file capabilities i
> > guess we're all set, but if both are going upstream, do you think
> > CONFIG_SECURITY_FILE_CAPABILITIES and selinux should be mutually
> > exclusive?
>
> We're already living in a non-stacking LSM environment, so whatever
> SELinux wants to do with capabilities is Stephen's affair, I suppose.
> I assume that this is in preparation for file based capabilities
Well it arguably obviates the need for file based capabilities :)
Stephen, I assume the intent would be to simply assign capabilities to
TE types, not to eventually add a new 'capability' field to the selinux
context akin to the mls field?
That changes how one uses these a bit, in an interesting way. Let's say
we want users running ping to get CAP_NET_RAW. If ping were then
exploited to exec something else, then with capabilities it would lose
CAP_NET_RAW. How should (or should?) that be emulated in selinux?
thanks,
-serge
> and dealing with interactions with them. My only concern is that you
> seem to be sneaking around the "additional restrictions" LSM model,
> with the justification being that the bit you're taking authority over
> is also an LSM module. I am not convinced that you're completely
> within the spirit of the thing, although I would hesitate to accuse
> you of not playing nicely quite yet.
>
>
>
> Casey Schaufler
> casey@schaufler-ca.com
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-11 22:24 ` Serge E. Hallyn
@ 2007-06-12 9:20 ` Russell Coker
2007-06-12 15:44 ` Serge E. Hallyn
2007-06-12 11:43 ` Stephen Smalley
1 sibling, 1 reply; 60+ messages in thread
From: Russell Coker @ 2007-06-12 9:20 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: Casey Schaufler, Stephen Smalley, selinux, James Morris,
Eric Paris
On Tuesday 12 June 2007 08:24, "Serge E. Hallyn" <serue@us.ibm.com> wrote:
> That changes how one uses these a bit, in an interesting way. Let's say
> we want users running ping to get CAP_NET_RAW. If ping were then
> exploited to exec something else, then with capabilities it would lose
> CAP_NET_RAW. How should (or should?) that be emulated in selinux?
The solution to this example is to not allow ping to execute anything - it has
no need to do so anyway. Also an attacker who exploited ping could probably
make it do whatever net-raw operations they desired without needing to
execute a different program.
For the general case of a privileged process executing another process you
want a domain_auto_trans.
--
russell@coker.com.au
http://etbe.coker.com.au/ My Blog
http://www.coker.com.au/sponsorship.html Sponsoring Free Software development
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-12 9:20 ` Russell Coker
@ 2007-06-12 15:44 ` Serge E. Hallyn
2007-06-12 15:57 ` Stephen Smalley
0 siblings, 1 reply; 60+ messages in thread
From: Serge E. Hallyn @ 2007-06-12 15:44 UTC (permalink / raw)
To: Russell Coker
Cc: Serge E. Hallyn, Casey Schaufler, Stephen Smalley, selinux,
James Morris, Eric Paris
Quoting Russell Coker (russell@coker.com.au):
> On Tuesday 12 June 2007 08:24, "Serge E. Hallyn" <serue@us.ibm.com> wrote:
> > That changes how one uses these a bit, in an interesting way. ?Let's say
> > we want users running ping to get CAP_NET_RAW. ?If ping were then
> > exploited to exec something else, then with capabilities it would lose
> > CAP_NET_RAW. ?How should (or should?) that be emulated in selinux?
>
> The solution to this example is to not allow ping to execute anything - it has
Yes I picked the example hoping you'd recognize that not being allowed
to execute anything is not a satisfactory solution in the general case.
Let me try another example - namespace cloning requires CAP_SYS_ADMIN,
and generally is followed by an execve. So if/when we provide a script
to start a vserver or checkpoint/restart job for ordinary users, we
would want it to run with CAP_SYS_ADMIN, then drop CAP_SYS_ADMIN on
execve.
> no need to do so anyway. Also an attacker who exploited ping could probably
> make it do whatever net-raw operations they desired without needing to
> execute a different program.
>
> For the general case of a privileged process executing another process you
> want a domain_auto_trans.
Ok, those can be forced, so I can't override it as a user?
Let's say I execute /usr/bin/restart_job, which has CAP_SYS_ADMIN in
order to clone some namespaces and then executes my restart job. I
started out as serge_u:serge_r:serge_t, and became
serge_u:serge_r:restartjob_t while running /usr/bin/restart_job. Now
when my checkpointed job is exec'ed, I might want to run in my original
context. Any sane way of doing that (and supporting it for various
users)? Do I just have to provide a bunch of domain_auto_trans rules
to transition to a bunch of users, and let the selinux user field select
which user I actually get transitioned to?
BTW - if the short answer is "we want to provide the *ability* to do
capability overrides but stick to the TE transition model in doing so,
that's fair too.
thanks,
-serge
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-12 15:44 ` Serge E. Hallyn
@ 2007-06-12 15:57 ` Stephen Smalley
2007-06-13 11:16 ` Russell Coker
0 siblings, 1 reply; 60+ messages in thread
From: Stephen Smalley @ 2007-06-12 15:57 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: Russell Coker, Casey Schaufler, selinux, James Morris, Eric Paris
On Tue, 2007-06-12 at 10:44 -0500, Serge E. Hallyn wrote:
> Quoting Russell Coker (russell@coker.com.au):
> > On Tuesday 12 June 2007 08:24, "Serge E. Hallyn" <serue@us.ibm.com> wrote:
> > > That changes how one uses these a bit, in an interesting way. ?Let's say
> > > we want users running ping to get CAP_NET_RAW. ?If ping were then
> > > exploited to exec something else, then with capabilities it would lose
> > > CAP_NET_RAW. ?How should (or should?) that be emulated in selinux?
> >
> > The solution to this example is to not allow ping to execute anything - it has
>
> Yes I picked the example hoping you'd recognize that not being allowed
> to execute anything is not a satisfactory solution in the general case.
>
> Let me try another example - namespace cloning requires CAP_SYS_ADMIN,
> and generally is followed by an execve. So if/when we provide a script
> to start a vserver or checkpoint/restart job for ordinary users, we
> would want it to run with CAP_SYS_ADMIN, then drop CAP_SYS_ADMIN on
> execve.
Well, first, no script should be allowed a capability that is not given
to its caller directly ;)
But the general goal here seems easy to address through TE domain
transitions.
> > no need to do so anyway. Also an attacker who exploited ping could probably
> > make it do whatever net-raw operations they desired without needing to
> > execute a different program.
> >
> > For the general case of a privileged process executing another process you
> > want a domain_auto_trans.
>
> Ok, those can be forced, so I can't override it as a user?
A domain cannot execute code at all (via execve or mmap PROT_EXEC)
without file:execute permission to its type and a domain cannot execve a
program in its own domain (i.e. without performing a domain transition)
without file:execute_no_trans permission to its type. Thus, one can
require a domain transition in order to execve a program, and then the
possible domain transitions are controlled in the usual way
(process:transition, file:entrypoint).
> Let's say I execute /usr/bin/restart_job, which has CAP_SYS_ADMIN in
> order to clone some namespaces and then executes my restart job. I
> started out as serge_u:serge_r:serge_t, and became
> serge_u:serge_r:restartjob_t while running /usr/bin/restart_job. Now
> when my checkpointed job is exec'ed, I might want to run in my original
> context. Any sane way of doing that (and supporting it for various
> users)? Do I just have to provide a bunch of domain_auto_trans rules
> to transition to a bunch of users, and let the selinux user field select
> which user I actually get transitioned to?
A common idiom in policy is a chain of domain derivations like:
domain_auto_trans(user_t, su_exec_t, user_su_t)
domain_auto_trans(user_su_t, shell_exec_t, user_t)
This takes you from the initial domain to the privileged domain and back
again. Not sure that you need to do this with per-user types though.
> BTW - if the short answer is "we want to provide the *ability* to do
> capability overrides but stick to the TE transition model in doing so,
> that's fair too.
>
> thanks,
> -serge
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-12 15:57 ` Stephen Smalley
@ 2007-06-13 11:16 ` Russell Coker
2007-06-13 12:31 ` Stephen Smalley
0 siblings, 1 reply; 60+ messages in thread
From: Russell Coker @ 2007-06-13 11:16 UTC (permalink / raw)
To: Stephen Smalley
Cc: Serge E. Hallyn, Casey Schaufler, selinux, James Morris,
Eric Paris
On Wednesday 13 June 2007 01:57, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> Well, first, no script should be allowed a capability that is not given
> to its caller directly ;)
Why not? Isn't that the entire point of this authoritative granting of
capabilities patch?
--
russell@coker.com.au
http://etbe.coker.com.au/ My Blog
http://www.coker.com.au/sponsorship.html Sponsoring Free Software development
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-13 11:16 ` Russell Coker
@ 2007-06-13 12:31 ` Stephen Smalley
2007-06-14 9:44 ` Russell Coker
0 siblings, 1 reply; 60+ messages in thread
From: Stephen Smalley @ 2007-06-13 12:31 UTC (permalink / raw)
To: russell; +Cc: Serge E. Hallyn, Casey Schaufler, selinux, James Morris,
Eric Paris
On Wed, 2007-06-13 at 21:16 +1000, Russell Coker wrote:
> On Wednesday 13 June 2007 01:57, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > Well, first, no script should be allowed a capability that is not given
> > to its caller directly ;)
>
> Why not? Isn't that the entire point of this authoritative granting of
> capabilities patch?
_script_, not program.
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-13 12:31 ` Stephen Smalley
@ 2007-06-14 9:44 ` Russell Coker
2007-06-14 11:03 ` Stephen Smalley
2007-06-14 13:54 ` Casey Schaufler
0 siblings, 2 replies; 60+ messages in thread
From: Russell Coker @ 2007-06-14 9:44 UTC (permalink / raw)
To: Stephen Smalley; +Cc: selinux
On Wednesday 13 June 2007 22:31, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On Wed, 2007-06-13 at 21:16 +1000, Russell Coker wrote:
> > On Wednesday 13 June 2007 01:57, Stephen Smalley <sds@tycho.nsa.gov>
wrote:
> > > Well, first, no script should be allowed a capability that is not given
> > > to its caller directly ;)
> >
> > Why not? Isn't that the entire point of this authoritative granting of
> > capabilities patch?
>
> _script_, not program.
OK, that's a bit of a topic change.
I've been thinking about the script issue. It seems to me that a problem we
face is the replacement of executables by scripts (which often happens in
distributions and sometimes happens with programs that are relevant to system
integrity).
We could write a policy that correctly allows a domain transition on executing
an ELF binary only to find that the next version of the distribution replaces
it with a BASH or Perl script then there is the potential for an exploit.
Apart from initrc_exec_t are we relying on domain transitions on execution of
shell scripts for anything?
Currently common shells have special-case code to deal with the case of
uid!=euid and gid!=egid. I think that this could be considered precedent for
having the shell check whether it is run in a different domain to it's parent
process, and if so whether the parent domain is permitted to execute
shell_exec_t in the current domain.
--
russell@coker.com.au
http://etbe.coker.com.au/ My Blog
http://www.coker.com.au/sponsorship.html Sponsoring Free Software development
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-14 9:44 ` Russell Coker
@ 2007-06-14 11:03 ` Stephen Smalley
2007-06-14 14:50 ` Stephen Smalley
2007-06-14 13:54 ` Casey Schaufler
1 sibling, 1 reply; 60+ messages in thread
From: Stephen Smalley @ 2007-06-14 11:03 UTC (permalink / raw)
To: russell; +Cc: selinux
On Thu, 2007-06-14 at 19:44 +1000, Russell Coker wrote:
> On Wednesday 13 June 2007 22:31, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > On Wed, 2007-06-13 at 21:16 +1000, Russell Coker wrote:
> > > On Wednesday 13 June 2007 01:57, Stephen Smalley <sds@tycho.nsa.gov>
> wrote:
> > > > Well, first, no script should be allowed a capability that is not given
> > > > to its caller directly ;)
> > >
> > > Why not? Isn't that the entire point of this authoritative granting of
> > > capabilities patch?
> >
> > _script_, not program.
>
> OK, that's a bit of a topic change.
>
> I've been thinking about the script issue. It seems to me that a problem we
> face is the replacement of executables by scripts (which often happens in
> distributions and sometimes happens with programs that are relevant to system
> integrity).
>
> We could write a policy that correctly allows a domain transition on executing
> an ELF binary only to find that the next version of the distribution replaces
> it with a BASH or Perl script then there is the potential for an exploit.
>
> Apart from initrc_exec_t are we relying on domain transitions on execution of
> shell scripts for anything?
It isn't just "shells", but any interpreter. cgi-bin scripts?
semanage? etc.
Solaris solution was to have the kernel create a fd to the script file
and pass /dev/fd/<n> as the first argument to the interpreter so that
there is no separate lookup when dealing with suid scripts. Naturally,
that doesn't address environmental contamination issues (and AT_SECURE
doesn't do enough cleansing to protect scripts), and it can yield
confusing results for scripts that aren't expecting their argv[0] to be
like that.
> Currently common shells have special-case code to deal with the case of
> uid!=euid and gid!=egid. I think that this could be considered precedent for
> having the shell check whether it is run in a different domain to it's parent
> process, and if so whether the parent domain is permitted to execute
> shell_exec_t in the current domain.
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-14 11:03 ` Stephen Smalley
@ 2007-06-14 14:50 ` Stephen Smalley
2007-06-14 14:54 ` Joshua Brindle
0 siblings, 1 reply; 60+ messages in thread
From: Stephen Smalley @ 2007-06-14 14:50 UTC (permalink / raw)
To: russell; +Cc: selinux, Joshua Brindle, Karl MacMillan
On Thu, 2007-06-14 at 07:03 -0400, Stephen Smalley wrote:
> On Thu, 2007-06-14 at 19:44 +1000, Russell Coker wrote:
> > On Wednesday 13 June 2007 22:31, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > > On Wed, 2007-06-13 at 21:16 +1000, Russell Coker wrote:
> > > > On Wednesday 13 June 2007 01:57, Stephen Smalley <sds@tycho.nsa.gov>
> > wrote:
> > > > > Well, first, no script should be allowed a capability that is not given
> > > > > to its caller directly ;)
> > > >
> > > > Why not? Isn't that the entire point of this authoritative granting of
> > > > capabilities patch?
> > >
> > > _script_, not program.
> >
> > OK, that's a bit of a topic change.
> >
> > I've been thinking about the script issue. It seems to me that a problem we
> > face is the replacement of executables by scripts (which often happens in
> > distributions and sometimes happens with programs that are relevant to system
> > integrity).
> >
> > We could write a policy that correctly allows a domain transition on executing
> > an ELF binary only to find that the next version of the distribution replaces
> > it with a BASH or Perl script then there is the potential for an exploit.
> >
> > Apart from initrc_exec_t are we relying on domain transitions on execution of
> > shell scripts for anything?
>
> It isn't just "shells", but any interpreter. cgi-bin scripts?
> semanage? etc.
>
> Solaris solution was to have the kernel create a fd to the script file
> and pass /dev/fd/<n> as the first argument to the interpreter so that
> there is no separate lookup when dealing with suid scripts. Naturally,
> that doesn't address environmental contamination issues (and AT_SECURE
> doesn't do enough cleansing to protect scripts), and it can yield
> confusing results for scripts that aren't expecting their argv[0] to be
> like that.
There was some discussion of introducing a binary wrapper for the python
scripts in policycoreutils to address this issue for them; python has a
template for such a binary wrapper in its source distribution.
> > Currently common shells have special-case code to deal with the case of
> > uid!=euid and gid!=egid. I think that this could be considered precedent for
> > having the shell check whether it is run in a different domain to it's parent
> > process, and if so whether the parent domain is permitted to execute
> > shell_exec_t in the current domain.
>
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-14 14:50 ` Stephen Smalley
@ 2007-06-14 14:54 ` Joshua Brindle
0 siblings, 0 replies; 60+ messages in thread
From: Joshua Brindle @ 2007-06-14 14:54 UTC (permalink / raw)
To: Stephen Smalley; +Cc: russell, selinux, Karl MacMillan
Stephen Smalley wrote:
> On Thu, 2007-06-14 at 07:03 -0400, Stephen Smalley wrote:
>
>> On Thu, 2007-06-14 at 19:44 +1000, Russell Coker wrote:
>>
>>> On Wednesday 13 June 2007 22:31, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>>>
>>>> On Wed, 2007-06-13 at 21:16 +1000, Russell Coker wrote:
>>>>
>>>>> On Wednesday 13 June 2007 01:57, Stephen Smalley <sds@tycho.nsa.gov>
>>>>>
>>> wrote:
>>>
>>>>>> Well, first, no script should be allowed a capability that is not given
>>>>>> to its caller directly ;)
>>>>>>
>>>>> Why not? Isn't that the entire point of this authoritative granting of
>>>>> capabilities patch?
>>>>>
>>>> _script_, not program.
>>>>
>>> OK, that's a bit of a topic change.
>>>
>>> I've been thinking about the script issue. It seems to me that a problem we
>>> face is the replacement of executables by scripts (which often happens in
>>> distributions and sometimes happens with programs that are relevant to system
>>> integrity).
>>>
>>> We could write a policy that correctly allows a domain transition on executing
>>> an ELF binary only to find that the next version of the distribution replaces
>>> it with a BASH or Perl script then there is the potential for an exploit.
>>>
>>> Apart from initrc_exec_t are we relying on domain transitions on execution of
>>> shell scripts for anything?
>>>
>> It isn't just "shells", but any interpreter. cgi-bin scripts?
>> semanage? etc.
>>
>> Solaris solution was to have the kernel create a fd to the script file
>> and pass /dev/fd/<n> as the first argument to the interpreter so that
>> there is no separate lookup when dealing with suid scripts. Naturally,
>> that doesn't address environmental contamination issues (and AT_SECURE
>> doesn't do enough cleansing to protect scripts), and it can yield
>> confusing results for scripts that aren't expecting their argv[0] to be
>> like that.
>>
>
> There was some discussion of introducing a binary wrapper for the python
> scripts in policycoreutils to address this issue for them; python has a
> template for such a binary wrapper in its source distribution.
>
>
Yes, CLIP has the wrapper on oss.tresys.com, I'll bug them to send it to
the list for inclusion into policycoreutils.
>>> Currently common shells have special-case code to deal with the case of
>>> uid!=euid and gid!=egid. I think that this could be considered precedent for
>>> having the shell check whether it is run in a different domain to it's parent
>>> process, and if so whether the parent domain is permitted to execute
>>> shell_exec_t in the current domain.
>>>
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-14 9:44 ` Russell Coker
2007-06-14 11:03 ` Stephen Smalley
@ 2007-06-14 13:54 ` Casey Schaufler
2007-06-14 14:50 ` Joshua Brindle
1 sibling, 1 reply; 60+ messages in thread
From: Casey Schaufler @ 2007-06-14 13:54 UTC (permalink / raw)
To: russell, Stephen Smalley; +Cc: selinux
--- Russell Coker <russell@coker.com.au> wrote:
> On Wednesday 13 June 2007 22:31, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > On Wed, 2007-06-13 at 21:16 +1000, Russell Coker wrote:
> > > On Wednesday 13 June 2007 01:57, Stephen Smalley <sds@tycho.nsa.gov>
> wrote:
> > > > Well, first, no script should be allowed a capability that is not given
> > > > to its caller directly ;)
> > >
> > > Why not? Isn't that the entire point of this authoritative granting of
> > > capabilities patch?
> >
> > _script_, not program.
>
> OK, that's a bit of a topic change.
>
> I've been thinking about the script issue. It seems to me that a problem we
> face is the replacement of executables by scripts (which often happens in
> distributions and sometimes happens with programs that are relevant to system
>
> integrity).
That should only be a problem on a name based system, right?
OK, sorry for the dig. Anyhow, it seems that the program that
sets the policy (labels the file system?) ought to be checking
the "type" of the file if it matters. You also might consider
that as 21st century programming (special purpose scripting)
replaces 20th century programming (general purpose binaries)
fewer people are going to be tolerent of a distintion between
a "program" and a "script" and look seriously at how you might
avoid having to treat them differently.
Casey Schaufler
casey@schaufler-ca.com
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-14 13:54 ` Casey Schaufler
@ 2007-06-14 14:50 ` Joshua Brindle
2007-06-14 15:05 ` Stephen Smalley
0 siblings, 1 reply; 60+ messages in thread
From: Joshua Brindle @ 2007-06-14 14:50 UTC (permalink / raw)
To: casey; +Cc: russell, Stephen Smalley, selinux
Casey Schaufler wrote:
> --- Russell Coker <russell@coker.com.au> wrote:
>
>
>> On Wednesday 13 June 2007 22:31, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>>
>>> On Wed, 2007-06-13 at 21:16 +1000, Russell Coker wrote:
>>>
>>>> On Wednesday 13 June 2007 01:57, Stephen Smalley <sds@tycho.nsa.gov>
>>>>
>> wrote:
>>
>>>>> Well, first, no script should be allowed a capability that is not given
>>>>> to its caller directly ;)
>>>>>
>>>> Why not? Isn't that the entire point of this authoritative granting of
>>>> capabilities patch?
>>>>
>>> _script_, not program.
>>>
>> OK, that's a bit of a topic change.
>>
>> I've been thinking about the script issue. It seems to me that a problem we
>> face is the replacement of executables by scripts (which often happens in
>> distributions and sometimes happens with programs that are relevant to system
>>
>> integrity).
>>
>
> That should only be a problem on a name based system, right?
>
> OK, sorry for the dig. Anyhow, it seems that the program that
> sets the policy (labels the file system?) ought to be checking
> the "type" of the file if it matters. You also might consider
> that as 21st century programming (special purpose scripting)
> replaces 20th century programming (general purpose binaries)
> fewer people are going to be tolerent of a distintion between
> a "program" and a "script" and look seriously at how you might
> avoid having to treat them differently.
>
We don't have to treat them differently if the interpreters will respect
ATSECURE and cleanse the environment across domain transitions or setuid
just like the linker does for compiled binaries. The race will still be
there but is alot harder to exploit than environment changes that change
the interpreter behavior.
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-14 14:50 ` Joshua Brindle
@ 2007-06-14 15:05 ` Stephen Smalley
0 siblings, 0 replies; 60+ messages in thread
From: Stephen Smalley @ 2007-06-14 15:05 UTC (permalink / raw)
To: Joshua Brindle; +Cc: casey, russell, selinux
On Thu, 2007-06-14 at 10:50 -0400, Joshua Brindle wrote:
> Casey Schaufler wrote:
> > --- Russell Coker <russell@coker.com.au> wrote:
> >
> >
> >> On Wednesday 13 June 2007 22:31, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> >>
> >>> On Wed, 2007-06-13 at 21:16 +1000, Russell Coker wrote:
> >>>
> >>>> On Wednesday 13 June 2007 01:57, Stephen Smalley <sds@tycho.nsa.gov>
> >>>>
> >> wrote:
> >>
> >>>>> Well, first, no script should be allowed a capability that is not given
> >>>>> to its caller directly ;)
> >>>>>
> >>>> Why not? Isn't that the entire point of this authoritative granting of
> >>>> capabilities patch?
> >>>>
> >>> _script_, not program.
> >>>
> >> OK, that's a bit of a topic change.
> >>
> >> I've been thinking about the script issue. It seems to me that a problem we
> >> face is the replacement of executables by scripts (which often happens in
> >> distributions and sometimes happens with programs that are relevant to system
> >>
> >> integrity).
> >>
> >
> > That should only be a problem on a name based system, right?
> >
> > OK, sorry for the dig. Anyhow, it seems that the program that
> > sets the policy (labels the file system?) ought to be checking
> > the "type" of the file if it matters. You also might consider
> > that as 21st century programming (special purpose scripting)
> > replaces 20th century programming (general purpose binaries)
> > fewer people are going to be tolerent of a distintion between
> > a "program" and a "script" and look seriously at how you might
> > avoid having to treat them differently.
> >
>
> We don't have to treat them differently if the interpreters will respect
> ATSECURE and cleanse the environment across domain transitions or setuid
> just like the linker does for compiled binaries. The race will still be
> there but is alot harder to exploit than environment changes that change
> the interpreter behavior.
Well...actually, the script lookup race has to be addressed or it is all
for naught - it really isn't that hard to exploit. You get to choose
the path by which you access the script.
The alternative of course is the binary wrapper approach, which works
with no kernel changes at all.
>From a quick look, it appears that perl and bash are still performing
fixed (uid != euid || gid != egid) tests rather than leveraging
AT_SECURE (of course, such a test would have to be in Linux-specific
code). perl also has the -T option to force tainting on, and python has
-E for the environment.
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-11 22:24 ` Serge E. Hallyn
2007-06-12 9:20 ` Russell Coker
@ 2007-06-12 11:43 ` Stephen Smalley
1 sibling, 0 replies; 60+ messages in thread
From: Stephen Smalley @ 2007-06-12 11:43 UTC (permalink / raw)
To: Serge E. Hallyn; +Cc: Casey Schaufler, selinux, James Morris, Eric Paris
On Mon, 2007-06-11 at 17:24 -0500, Serge E. Hallyn wrote:
> Quoting Casey Schaufler (casey@schaufler-ca.com):
> >
> > --- "Serge E. Hallyn" <serue@us.ibm.com> wrote:
> >
> > > Quoting Stephen Smalley (sds@tycho.nsa.gov):
> > > > Extend SELinux to allow capabilities to be granted authoritatively.
> > > > Introduces a new cap_override access vector to indicate when the
> > > > secondary module (i.e. capability or dummy) check should be skipped.
> > > > Handle the new class gracefully even if the policy does not yet have
> > > > it defined.
> > >
> > > Cool.
> > >
> > > If we decide to have this take the place of the file capabilities i
> > > guess we're all set, but if both are going upstream, do you think
> > > CONFIG_SECURITY_FILE_CAPABILITIES and selinux should be mutually
> > > exclusive?
> >
> > We're already living in a non-stacking LSM environment, so whatever
> > SELinux wants to do with capabilities is Stephen's affair, I suppose.
> > I assume that this is in preparation for file based capabilities
>
> Well it arguably obviates the need for file based capabilities :)
>
> Stephen, I assume the intent would be to simply assign capabilities to
> TE types, not to eventually add a new 'capability' field to the selinux
> context akin to the mls field?
Correct. We were already authorizing the use of capabilities in SELinux
policy via e.g.:
allow foo_t self:capability dac_override;
But the foo_t process had to already have obtained that capability in
the first place, e.g. by being invoked by a uid 0 process or by being
setuid root. With this change, we can now add a second allow rule:
allow foo_t self:cap_override dac_override;
if we want foo_t to be able to use that capability without ever having
been uid 0. But we still have the choice of only granting the first
rule when we don't want this behavior, and only the first rule will ever
show up from audit2allow (due to the use of _noaudit) - the second one
will always be an explicit choice by a policy writer.
> That changes how one uses these a bit, in an interesting way. Let's say
> we want users running ping to get CAP_NET_RAW. If ping were then
> exploited to exec something else, then with capabilities it would lose
> CAP_NET_RAW. How should (or should?) that be emulated in selinux?
SELinux already provides controls over what each domain can execute, so
that is simply a matter of preventing ping from executing other code in
SELinux policy, and/or defining domain transitions to less privileged
domains when ping does execute another program.
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-11 21:43 ` Casey Schaufler
2007-06-11 22:20 ` James Morris
2007-06-11 22:24 ` Serge E. Hallyn
@ 2007-06-12 11:31 ` Stephen Smalley
2 siblings, 0 replies; 60+ messages in thread
From: Stephen Smalley @ 2007-06-12 11:31 UTC (permalink / raw)
To: casey; +Cc: Serge E. Hallyn, selinux, James Morris, Eric Paris
On Mon, 2007-06-11 at 14:43 -0700, Casey Schaufler wrote:
> --- "Serge E. Hallyn" <serue@us.ibm.com> wrote:
>
> > Quoting Stephen Smalley (sds@tycho.nsa.gov):
> > > Extend SELinux to allow capabilities to be granted authoritatively.
> > > Introduces a new cap_override access vector to indicate when the
> > > secondary module (i.e. capability or dummy) check should be skipped.
> > > Handle the new class gracefully even if the policy does not yet have
> > > it defined.
> >
> > Cool.
> >
> > If we decide to have this take the place of the file capabilities i
> > guess we're all set, but if both are going upstream, do you think
> > CONFIG_SECURITY_FILE_CAPABILITIES and selinux should be mutually
> > exclusive?
>
> We're already living in a non-stacking LSM environment, so whatever
> SELinux wants to do with capabilities is Stephen's affair, I suppose.
> I assume that this is in preparation for file based capabilities
> and dealing with interactions with them. My only concern is that you
> seem to be sneaking around the "additional restrictions" LSM model,
> with the justification being that the bit you're taking authority over
> is also an LSM module. I am not convinced that you're completely
> within the spirit of the thing, although I would hesitate to accuse
> you of not playing nicely quite yet.
First, I don't think this has to be mutually exclusive of file
capabilities. Each of them provides a way to grant capabilities to
programs.
Second, this isn't a misuse of LSM; it follows naturally from the fact
that LSM defines the capable() hook entirely (there is no base logic -
it was all moved into the capability module) and thus can
authoritatively grant capabilities. The only reason that SELinux is
presently restrictive wrt to capabilities is because we have it calling
the secondary module. Also, it seems that FreeBSD is going down this
path of using their MAC framework to authoritatively control their
privileges.
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-11 20:43 ` Serge E. Hallyn
2007-06-11 21:43 ` Casey Schaufler
@ 2007-06-12 9:27 ` Russell Coker
2007-06-12 12:09 ` Stephen Smalley
1 sibling, 1 reply; 60+ messages in thread
From: Russell Coker @ 2007-06-12 9:27 UTC (permalink / raw)
To: Serge E. Hallyn; +Cc: Stephen Smalley, selinux, James Morris, Eric Paris
On Tuesday 12 June 2007 06:43, "Serge E. Hallyn" <serue@us.ibm.com> wrote:
> If we decide to have this take the place of the file capabilities i
> guess we're all set, but if both are going upstream, do you think
> CONFIG_SECURITY_FILE_CAPABILITIES and selinux should be mutually
> exclusive?
This is the sort of thing that can be revised at some future time when there
are some users for FILE_CAPABILITIES. While there are no users for either of
the options there seems little incentive to make them work together in the
short term.
The potential interactions between FILE_CAPABILITIES and cap_override are not
obvious, I can think of several options for how these things might work -
basically determining how much SE Linux will permit FILE_CAPABILITIES to do
what it wants. If we are going to make them work together then before code
is written it would probably be more effective to have some agreement on how
it will work - which will depend on some sample implementations of both
systems and public comment.
--
russell@coker.com.au
http://etbe.coker.com.au/ My Blog
http://www.coker.com.au/sponsorship.html Sponsoring Free Software development
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-12 9:27 ` Russell Coker
@ 2007-06-12 12:09 ` Stephen Smalley
0 siblings, 0 replies; 60+ messages in thread
From: Stephen Smalley @ 2007-06-12 12:09 UTC (permalink / raw)
To: russell; +Cc: Serge E. Hallyn, selinux, James Morris, Eric Paris
On Tue, 2007-06-12 at 19:27 +1000, Russell Coker wrote:
> On Tuesday 12 June 2007 06:43, "Serge E. Hallyn" <serue@us.ibm.com> wrote:
> > If we decide to have this take the place of the file capabilities i
> > guess we're all set, but if both are going upstream, do you think
> > CONFIG_SECURITY_FILE_CAPABILITIES and selinux should be mutually
> > exclusive?
>
> This is the sort of thing that can be revised at some future time when there
> are some users for FILE_CAPABILITIES. While there are no users for either of
> the options there seems little incentive to make them work together in the
> short term.
>
> The potential interactions between FILE_CAPABILITIES and cap_override are not
> obvious, I can think of several options for how these things might work -
> basically determining how much SE Linux will permit FILE_CAPABILITIES to do
> what it wants. If we are going to make them work together then before code
> is written it would probably be more effective to have some agreement on how
> it will work - which will depend on some sample implementations of both
> systems and public comment.
Serge's file capabilities patch is already in -mm, so it is fairly
straightforward to see how they interact currently. The SELinux
checking is applied when a process tries to use a capability, whereas
the file capabilities logic is applied when the process' capability
masks are computed at execve time. Thus, the file capabilities logic
merely changes the base Linux capability computation upon execve and
affects the process' capability mask that is later checked on use. The
old SELinux logic checked the process' capability mask (via the
capability module), and then if granted there, it would apply the
SELinux capability check as a further restriction. The new SELinux
logic checks the SELinux cap_override check first; if that is denied,
then all is as it was before; if it is allowed, then the process'
capability mask is ignored and the SELinux capability check can
authoritatively grant the capability.
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-11 19:55 [RFC][PATCH] selinux: enable authoritative granting of capabilities Stephen Smalley
2007-06-11 20:39 ` James Morris
2007-06-11 20:43 ` Serge E. Hallyn
@ 2007-06-12 12:50 ` Stephen Smalley
2007-06-12 15:08 ` Casey Schaufler
2007-06-12 16:03 ` Serge E. Hallyn
2007-06-12 13:24 ` Stephen Smalley
2007-06-12 13:32 ` Stephen Smalley
4 siblings, 2 replies; 60+ messages in thread
From: Stephen Smalley @ 2007-06-12 12:50 UTC (permalink / raw)
To: selinux; +Cc: James Morris, Eric Paris, Serge E. Hallyn
On Mon, 2007-06-11 at 15:55 -0400, Stephen Smalley wrote:
> Extend SELinux to allow capabilities to be granted authoritatively.
> Introduces a new cap_override access vector to indicate when the
> secondary module (i.e. capability or dummy) check should be skipped.
> Handle the new class gracefully even if the policy does not yet have
> it defined.
I was asked privately to explain what motivated this patch. As the
answer is likely of general interest, here is a summary of (and
expansion upon) my reply. I'll likely fold some of this text into the
description that goes with the final form of this patch.
The idea of using SELinux RBAC/TE to completely manage Linux
capabilities has always been desirable from our point of view, and was
described in the earliest discussions on selinux list (see archives). A
similar approach to superuser privilege overrides was even implemented
in a predecessor of SELinux, the DTOS system. We had held off on it
originally in SELinux because of the potential danger in weakening the
base system restrictions, but it has always remained a goal, deferred
until SELinux was more fully integrated and policy was more mature.
The motivation for creating this patch now has been the flurry of
interest/activity in file capabilities (currently a patch in -mm), which
provide an alternative (and in our view inferior) way to achieve the
same end - being able to grant capabilities to programs without them
needing to be suid root. But the file capabilities approach lacks a
centralized and analyzable policy, the flexibility and control of domain
transitions for changes in capability state (vs. the hardcoded
capability evolution logic), and the ability to protect and confine the
processes that are given these capabilities.
This patch as implemented makes the distinction very clear:
allow ping_t self:capability net_raw; still means what it used to
mean, and SELinux will only authoritatively grant the capability if you
add a new cap_override rule to the policy, e.g.
allow ping_t self:cap_override new_raw;
Thus, by default (in the absence of new policy), nothing changes, and
anyone can easily audit their policy to see whether and where they are
granting capabilities authoritatively.
Further, as the code uses the _noaudit interface to apply the
cap_override check, these permissions will only be allowed by explicit
choice of the administrator, not by automated policy generation tools
like audit2allow. The use of the _noaudit interface was also motivated
by the fact that this check must occur before the base capability check
and would otherwise need to be pervasively dontaudit'd to avoid noise in
the audit logs.
At present, the patch clones the capability permissions into the
cap_override class; I would have moved them to a common definition and
inherited them into both but that would have prevented policy reload on
existing kernels.
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-12 12:50 ` Stephen Smalley
@ 2007-06-12 15:08 ` Casey Schaufler
2007-06-12 15:33 ` Stephen Smalley
2007-06-12 16:03 ` Serge E. Hallyn
1 sibling, 1 reply; 60+ messages in thread
From: Casey Schaufler @ 2007-06-12 15:08 UTC (permalink / raw)
To: Stephen Smalley, selinux; +Cc: James Morris, Eric Paris, Serge E. Hallyn
--- Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On Mon, 2007-06-11 at 15:55 -0400, Stephen Smalley wrote:
> > Extend SELinux to allow capabilities to be granted authoritatively.
> > Introduces a new cap_override access vector to indicate when the
> > secondary module (i.e. capability or dummy) check should be skipped.
> > Handle the new class gracefully even if the policy does not yet have
> > it defined.
>
> I was asked privately to explain what motivated this patch. As the
> answer is likely of general interest, here is a summary of (and
> expansion upon) my reply. I'll likely fold some of this text into the
> description that goes with the final form of this patch.
Thank you for taking the time to provide this.
> The idea of using SELinux RBAC/TE to completely manage Linux
> capabilities has always been desirable from our point of view, and was
> described in the earliest discussions on selinux list (see archives). A
> similar approach to superuser privilege overrides was even implemented
> in a predecessor of SELinux, the DTOS system. We had held off on it
> originally in SELinux because of the potential danger in weakening the
> base system restrictions, but it has always remained a goal, deferred
> until SELinux was more fully integrated and policy was more mature.
>
> The motivation for creating this patch now has been the flurry of
> interest/activity in file capabilities (currently a patch in -mm), which
> provide an alternative (and in our view inferior) way to achieve the
> same end - being able to grant capabilities to programs without them
> needing to be suid root. But the file capabilities approach lacks a
> centralized and analyzable policy, the flexibility and control of domain
> transitions for changes in capability state (vs. the hardcoded
> capability evolution logic), and the ability to protect and confine the
> processes that are given these capabilities.
The file capabilty mechanism has been through two CC evaluations
for which I have the certificates, so I think that you may have
trouble substantiating your claim that it lacks an analyzable policy.
> This patch as implemented makes the distinction very clear:
> allow ping_t self:capability net_raw; still means what it used to
> mean, and SELinux will only authoritatively grant the capability if you
> add a new cap_override rule to the policy, e.g.
> allow ping_t self:cap_override new_raw;
>
> Thus, by default (in the absence of new policy), nothing changes, and
> anyone can easily audit their policy to see whether and where they are
> granting capabilities authoritatively.
>
> Further, as the code uses the _noaudit interface to apply the
> cap_override check, these permissions will only be allowed by explicit
> choice of the administrator, not by automated policy generation tools
> like audit2allow. The use of the _noaudit interface was also motivated
> by the fact that this check must occur before the base capability check
> and would otherwise need to be pervasively dontaudit'd to avoid noise in
> the audit logs.
>
> At present, the patch clones the capability permissions into the
> cap_override class; I would have moved them to a common definition and
> inherited them into both but that would have prevented policy reload on
> existing kernels.
Well, I don't like it, but I do appreciate the fact that the
disintegration is explicit.
Do y'all plan to let the rest of the world know what you're up
to, or do you plan to present this as a feit accompli?
Casey Schaufler
casey@schaufler-ca.com
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-12 15:08 ` Casey Schaufler
@ 2007-06-12 15:33 ` Stephen Smalley
2007-06-12 16:38 ` Casey Schaufler
0 siblings, 1 reply; 60+ messages in thread
From: Stephen Smalley @ 2007-06-12 15:33 UTC (permalink / raw)
To: casey; +Cc: selinux, James Morris, Eric Paris, Serge E. Hallyn
On Tue, 2007-06-12 at 08:08 -0700, Casey Schaufler wrote:
> --- Stephen Smalley <sds@tycho.nsa.gov> wrote:
>
> > On Mon, 2007-06-11 at 15:55 -0400, Stephen Smalley wrote:
> > > Extend SELinux to allow capabilities to be granted authoritatively.
> > > Introduces a new cap_override access vector to indicate when the
> > > secondary module (i.e. capability or dummy) check should be skipped.
> > > Handle the new class gracefully even if the policy does not yet have
> > > it defined.
> >
> > I was asked privately to explain what motivated this patch. As the
> > answer is likely of general interest, here is a summary of (and
> > expansion upon) my reply. I'll likely fold some of this text into the
> > description that goes with the final form of this patch.
>
> Thank you for taking the time to provide this.
>
> > The idea of using SELinux RBAC/TE to completely manage Linux
> > capabilities has always been desirable from our point of view, and was
> > described in the earliest discussions on selinux list (see archives). A
> > similar approach to superuser privilege overrides was even implemented
> > in a predecessor of SELinux, the DTOS system. We had held off on it
> > originally in SELinux because of the potential danger in weakening the
> > base system restrictions, but it has always remained a goal, deferred
> > until SELinux was more fully integrated and policy was more mature.
> >
> > The motivation for creating this patch now has been the flurry of
> > interest/activity in file capabilities (currently a patch in -mm), which
> > provide an alternative (and in our view inferior) way to achieve the
> > same end - being able to grant capabilities to programs without them
> > needing to be suid root. But the file capabilities approach lacks a
> > centralized and analyzable policy, the flexibility and control of domain
> > transitions for changes in capability state (vs. the hardcoded
> > capability evolution logic), and the ability to protect and confine the
> > processes that are given these capabilities.
>
> The file capabilty mechanism has been through two CC evaluations
> for which I have the certificates, so I think that you may have
> trouble substantiating your claim that it lacks an analyzable policy.
I'll clarify: The file capability mechanism encodes policy in the
filesystem state on a per-file basis, so to analyze the effective policy
of the system, you have to snapshot the current per-file capability
bitmaps scattered throughout your filesystem, and even then, your
ability to analyze reachability is limited by the lack of explicit
transition controls. Versus being able to analyze a TE policy where the
capability state is directly encoded based on equivalence classes
(types), and you can directly check reachability all without looking at
the filesystem state.
> > This patch as implemented makes the distinction very clear:
> > allow ping_t self:capability net_raw; still means what it used to
> > mean, and SELinux will only authoritatively grant the capability if you
> > add a new cap_override rule to the policy, e.g.
> > allow ping_t self:cap_override new_raw;
> >
> > Thus, by default (in the absence of new policy), nothing changes, and
> > anyone can easily audit their policy to see whether and where they are
> > granting capabilities authoritatively.
> >
> > Further, as the code uses the _noaudit interface to apply the
> > cap_override check, these permissions will only be allowed by explicit
> > choice of the administrator, not by automated policy generation tools
> > like audit2allow. The use of the _noaudit interface was also motivated
> > by the fact that this check must occur before the base capability check
> > and would otherwise need to be pervasively dontaudit'd to avoid noise in
> > the audit logs.
> >
> > At present, the patch clones the capability permissions into the
> > cap_override class; I would have moved them to a common definition and
> > inherited them into both but that would have prevented policy reload on
> > existing kernels.
>
> Well, I don't like it, but I do appreciate the fact that the
> disintegration is explicit.
>
> Do y'all plan to let the rest of the world know what you're up
> to, or do you plan to present this as a feit accompli?
I'm not sure what that means. It is just a patch to selinux (it touches
no other code, and has no side effects in the absence of new policy),
and it would go in via the usual route, which ultimately should include
posting to linux-kernel. No different than a patch to any other kernel
subsystem.
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-12 15:33 ` Stephen Smalley
@ 2007-06-12 16:38 ` Casey Schaufler
2007-06-12 17:49 ` James Morris
0 siblings, 1 reply; 60+ messages in thread
From: Casey Schaufler @ 2007-06-12 16:38 UTC (permalink / raw)
To: Stephen Smalley, casey; +Cc: selinux, James Morris, Eric Paris, Serge E. Hallyn
--- Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On Tue, 2007-06-12 at 08:08 -0700, Casey Schaufler wrote:
> ...
> >
> > The file capabilty mechanism has been through two CC evaluations
> > for which I have the certificates, so I think that you may have
> > trouble substantiating your claim that it lacks an analyzable policy.
>
> I'll clarify: The file capability mechanism encodes policy in the
> filesystem state on a per-file basis,
Uh, yeah. They are stored in extended attributes. This provides
superior locality of reference. Extended attributes are a good
thing for security mechanisms, just have a read through the threads
about AA on the LSM list.
> so to analyze the effective policy
> of the system, you have to snapshot the current per-file capability
> bitmaps scattered throughout your filesystem,
You need to know where you've put them. It's not a matter of going
out and finding them, it's a matter of being careful where you
put them in the first place. You make it sound hard. It isn't,
and it has been done successfully.
> and even then, your
> ability to analyze reachability is limited by the lack of explicit
> transition controls. Versus being able to analyze a TE policy where the
> capability state is directly encoded based on equivalence classes
> (types), and you can directly check reachability all without looking at
> the filesystem state.
It's true. Capabilities don't implement TE. They aren't intended
to, and the arguement that they are flawwed because they don't is
distracting.
> ...
> >
> > Well, I don't like it, but I do appreciate the fact that the
> > disintegration is explicit.
> >
> > Do y'all plan to let the rest of the world know what you're up
> > to, or do you plan to present this as a feit accompli?
>
> I'm not sure what that means. It is just a patch to selinux (it touches
> no other code, and has no side effects in the absence of new policy),
> and it would go in via the usual route, which ultimately should include
> posting to linux-kernel. No different than a patch to any other kernel
> subsystem.
Always be wary when Stephen says "just"!
You're right, you are "just" changing the way SELinux uses existing
interfaces. You are "just" abandoning the notion of LSM stacking.
You are "just" taking the first step toward replacing the Linux
security model with the SELinux security model.
And you are correct, it's all being done within framework, policy,
and procedures. Groan Grumble Snort Complain. Well, carry on then.
Casey Schaufler
casey@schaufler-ca.com
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-12 16:38 ` Casey Schaufler
@ 2007-06-12 17:49 ` James Morris
2007-06-12 19:56 ` Casey Schaufler
0 siblings, 1 reply; 60+ messages in thread
From: James Morris @ 2007-06-12 17:49 UTC (permalink / raw)
To: Casey Schaufler; +Cc: Stephen Smalley, selinux, Eric Paris, Serge E. Hallyn
On Tue, 12 Jun 2007, Casey Schaufler wrote:
>
> --- Stephen Smalley <sds@tycho.nsa.gov> wrote:
>
> > On Tue, 2007-06-12 at 08:08 -0700, Casey Schaufler wrote:
> > ...
> > >
> > > The file capabilty mechanism has been through two CC evaluations
> > > for which I have the certificates, so I think that you may have
> > > trouble substantiating your claim that it lacks an analyzable policy.
> >
> > I'll clarify: The file capability mechanism encodes policy in the
> > filesystem state on a per-file basis,
>
> Uh, yeah. They are stored in extended attributes. This provides
> superior locality of reference. Extended attributes are a good
> thing for security mechanisms, just have a read through the threads
> about AA on the LSM list.
The important thing to differentiate here is that filesystem capabilities
stores _policy_ in the filesystem, as opposed to security attributes of
filesystem objects.
- James
--
James Morris
<jmorris@namei.org>
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-12 17:49 ` James Morris
@ 2007-06-12 19:56 ` Casey Schaufler
0 siblings, 0 replies; 60+ messages in thread
From: Casey Schaufler @ 2007-06-12 19:56 UTC (permalink / raw)
To: James Morris, Casey Schaufler
Cc: Stephen Smalley, selinux, Eric Paris, Serge E. Hallyn
--- James Morris <jmorris@namei.org> wrote:
> On Tue, 12 Jun 2007, Casey Schaufler wrote:
>
> >
> > --- Stephen Smalley <sds@tycho.nsa.gov> wrote:
> >
> > > On Tue, 2007-06-12 at 08:08 -0700, Casey Schaufler wrote:
> > > ...
> > > >
> > > > The file capabilty mechanism has been through two CC evaluations
> > > > for which I have the certificates, so I think that you may have
> > > > trouble substantiating your claim that it lacks an analyzable policy.
> > >
> > > I'll clarify: The file capability mechanism encodes policy in the
> > > filesystem state on a per-file basis,
> >
> > Uh, yeah. They are stored in extended attributes. This provides
> > superior locality of reference. Extended attributes are a good
> > thing for security mechanisms, just have a read through the threads
> > about AA on the LSM list.
>
> The important thing to differentiate here is that filesystem capabilities
> stores _policy_ in the filesystem, as opposed to security attributes of
> filesystem objects.
What, it's bad to tightly associate the policy with the executable?
That's crazy talk. The capability vector of a program belongs attached
to the program. How many other components of the security policy (e.g.
DAC bits, MLS labels, owner, owning group, setuid bit) are attached to
the program? And don't go saying that the setuid bits has nothing to
do with policy, I'll hit you over the head with an evaluation report.
Please remember (or learn) that the SELinux way of doing things is
the exception rather than the rule for associating "policy" with
program behavior. Systems have been associating "policy" directly
with executables for decades. The notion of an external policy
definition still gives some of us old farts the heebeejeebees.
Casey Schaufler
casey@schaufler-ca.com
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-12 12:50 ` Stephen Smalley
2007-06-12 15:08 ` Casey Schaufler
@ 2007-06-12 16:03 ` Serge E. Hallyn
1 sibling, 0 replies; 60+ messages in thread
From: Serge E. Hallyn @ 2007-06-12 16:03 UTC (permalink / raw)
To: Stephen Smalley; +Cc: selinux, James Morris, Eric Paris, Serge E. Hallyn
Quoting Stephen Smalley (sds@tycho.nsa.gov):
> On Mon, 2007-06-11 at 15:55 -0400, Stephen Smalley wrote:
> > Extend SELinux to allow capabilities to be granted authoritatively.
> > Introduces a new cap_override access vector to indicate when the
> > secondary module (i.e. capability or dummy) check should be skipped.
> > Handle the new class gracefully even if the policy does not yet have
> > it defined.
>
> I was asked privately to explain what motivated this patch. As the
> answer is likely of general interest, here is a summary of (and
> expansion upon) my reply. I'll likely fold some of this text into the
> description that goes with the final form of this patch.
>
> The idea of using SELinux RBAC/TE to completely manage Linux
> capabilities has always been desirable from our point of view, and was
Yup, I think this is great. When James mentioned the idea earlier in
the thread I thought it would be closer to 'file capabilities
implemented in selinux', but there's really no reason for it to be.
This fits better with the existing model, and now the full
restrictions+privilege of a process can be known in one policy, which is
*clearly* a good thing.
thanks,
-serge
> described in the earliest discussions on selinux list (see archives). A
> similar approach to superuser privilege overrides was even implemented
> in a predecessor of SELinux, the DTOS system. We had held off on it
> originally in SELinux because of the potential danger in weakening the
> base system restrictions, but it has always remained a goal, deferred
> until SELinux was more fully integrated and policy was more mature.
>
> The motivation for creating this patch now has been the flurry of
> interest/activity in file capabilities (currently a patch in -mm), which
> provide an alternative (and in our view inferior) way to achieve the
> same end - being able to grant capabilities to programs without them
> needing to be suid root. But the file capabilities approach lacks a
> centralized and analyzable policy, the flexibility and control of domain
> transitions for changes in capability state (vs. the hardcoded
> capability evolution logic), and the ability to protect and confine the
> processes that are given these capabilities.
>
> This patch as implemented makes the distinction very clear:
> allow ping_t self:capability net_raw; still means what it used to
> mean, and SELinux will only authoritatively grant the capability if you
> add a new cap_override rule to the policy, e.g.
> allow ping_t self:cap_override new_raw;
>
> Thus, by default (in the absence of new policy), nothing changes, and
> anyone can easily audit their policy to see whether and where they are
> granting capabilities authoritatively.
>
> Further, as the code uses the _noaudit interface to apply the
> cap_override check, these permissions will only be allowed by explicit
> choice of the administrator, not by automated policy generation tools
> like audit2allow. The use of the _noaudit interface was also motivated
> by the fact that this check must occur before the base capability check
> and would otherwise need to be pervasively dontaudit'd to avoid noise in
> the audit logs.
>
> At present, the patch clones the capability permissions into the
> cap_override class; I would have moved them to a common definition and
> inherited them into both but that would have prevented policy reload on
> existing kernels.
>
> --
> Stephen Smalley
> National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-11 19:55 [RFC][PATCH] selinux: enable authoritative granting of capabilities Stephen Smalley
` (2 preceding siblings ...)
2007-06-12 12:50 ` Stephen Smalley
@ 2007-06-12 13:24 ` Stephen Smalley
2007-06-12 20:50 ` Stephen Smalley
2007-06-12 13:32 ` Stephen Smalley
4 siblings, 1 reply; 60+ messages in thread
From: Stephen Smalley @ 2007-06-12 13:24 UTC (permalink / raw)
To: selinux; +Cc: James Morris, Eric Paris, Serge E. Hallyn,
Christopher J. PeBenito
[-- Attachment #1: Type: text/plain, Size: 866 bytes --]
On Mon, 2007-06-11 at 15:55 -0400, Stephen Smalley wrote:
> Extend SELinux to allow capabilities to be granted authoritatively.
> Introduces a new cap_override access vector to indicate when the
> secondary module (i.e. capability or dummy) check should be skipped.
> Handle the new class gracefully even if the policy does not yet have
> it defined.
For people who want to test/experiment with this kernel patch, below is
the policy patch I used to define the new class and permissions (it also
includes the previously added memprotect class since that hasn't been
added upstream yet). If you rebuild your base policy with this patch
(e.g. grab the source package, add this patch, rebuild and reinstall),
then you can subsequently create loadable policy modules that use the
new cap_override permissions for testing.
--
Stephen Smalley
National Security Agency
[-- Attachment #2: policy-capoverride.diff --]
[-- Type: text/x-patch, Size: 1420 bytes --]
Index: refpolicy/policy/flask/security_classes
===================================================================
--- refpolicy/policy/flask/security_classes (revision 2324)
+++ refpolicy/policy/flask/security_classes (working copy)
@@ -97,4 +97,8 @@
class dccp_socket
+class memprotect
+
+class cap_override
+
# FLASK
Index: refpolicy/policy/flask/access_vectors
===================================================================
--- refpolicy/policy/flask/access_vectors (revision 2324)
+++ refpolicy/policy/flask/access_vectors (working copy)
@@ -648,3 +648,47 @@
node_bind
name_connect
}
+
+class memprotect
+{
+ mmap_zero
+}
+
+class cap_override
+{
+ # The capabilities are defined in include/linux/capability.h
+ # Care should be taken to ensure that these are consistent with
+ # those definitions. (Order matters)
+
+ chown
+ dac_override
+ dac_read_search
+ fowner
+ fsetid
+ kill
+ setgid
+ setuid
+ setpcap
+ linux_immutable
+ net_bind_service
+ net_broadcast
+ net_admin
+ net_raw
+ ipc_lock
+ ipc_owner
+ sys_module
+ sys_rawio
+ sys_chroot
+ sys_ptrace
+ sys_pacct
+ sys_admin
+ sys_boot
+ sys_nice
+ sys_resource
+ sys_time
+ sys_tty_config
+ mknod
+ lease
+ audit_write
+ audit_control
+}
^ permalink raw reply [flat|nested] 60+ messages in thread* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-12 13:24 ` Stephen Smalley
@ 2007-06-12 20:50 ` Stephen Smalley
2007-06-12 21:12 ` Stephen Smalley
0 siblings, 1 reply; 60+ messages in thread
From: Stephen Smalley @ 2007-06-12 20:50 UTC (permalink / raw)
To: selinux
Cc: James Morris, Eric Paris, Serge E. Hallyn,
Christopher J. PeBenito, Daniel J Walsh
On Tue, 2007-06-12 at 09:24 -0400, Stephen Smalley wrote:
> On Mon, 2007-06-11 at 15:55 -0400, Stephen Smalley wrote:
> > Extend SELinux to allow capabilities to be granted authoritatively.
> > Introduces a new cap_override access vector to indicate when the
> > secondary module (i.e. capability or dummy) check should be skipped.
> > Handle the new class gracefully even if the policy does not yet have
> > it defined.
>
> For people who want to test/experiment with this kernel patch, below is
> the policy patch I used to define the new class and permissions (it also
> includes the previously added memprotect class since that hasn't been
> added upstream yet). If you rebuild your base policy with this patch
> (e.g. grab the source package, add this patch, rebuild and reinstall),
> then you can subsequently create loadable policy modules that use the
> new cap_override permissions for testing.
One thing to note is that the applicability of this approach under
targeted policy seems somewhat limited, as we have to ensure that a
DAC-unprivileged process in unconfined_t (like an ordinary user shell)
cannot ultimately gain unauthorized access to these capabilities granted
to another domain, but at present, confined domains are always at the
mercy of unconfined_t.
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-12 20:50 ` Stephen Smalley
@ 2007-06-12 21:12 ` Stephen Smalley
2007-06-13 14:31 ` Stephen Smalley
0 siblings, 1 reply; 60+ messages in thread
From: Stephen Smalley @ 2007-06-12 21:12 UTC (permalink / raw)
To: selinux
Cc: James Morris, Eric Paris, Serge E. Hallyn,
Christopher J. PeBenito, Daniel J Walsh, Karl MacMillan
On Tue, 2007-06-12 at 16:50 -0400, Stephen Smalley wrote:
> On Tue, 2007-06-12 at 09:24 -0400, Stephen Smalley wrote:
> > On Mon, 2007-06-11 at 15:55 -0400, Stephen Smalley wrote:
> > > Extend SELinux to allow capabilities to be granted authoritatively.
> > > Introduces a new cap_override access vector to indicate when the
> > > secondary module (i.e. capability or dummy) check should be skipped.
> > > Handle the new class gracefully even if the policy does not yet have
> > > it defined.
> >
> > For people who want to test/experiment with this kernel patch, below is
> > the policy patch I used to define the new class and permissions (it also
> > includes the previously added memprotect class since that hasn't been
> > added upstream yet). If you rebuild your base policy with this patch
> > (e.g. grab the source package, add this patch, rebuild and reinstall),
> > then you can subsequently create loadable policy modules that use the
> > new cap_override permissions for testing.
>
> One thing to note is that the applicability of this approach under
> targeted policy seems somewhat limited, as we have to ensure that a
> DAC-unprivileged process in unconfined_t (like an ordinary user shell)
> cannot ultimately gain unauthorized access to these capabilities granted
> to another domain, but at present, confined domains are always at the
> mercy of unconfined_t.
I suppose we would need to ensure that even the unconfined domains are
not given certain permissions (e.g. ptrace, sig*, setsched) to any
domain that is allowed these overrides. That should be equivalent to
the same restrictions imposed by the file capabilities code.
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-12 21:12 ` Stephen Smalley
@ 2007-06-13 14:31 ` Stephen Smalley
2007-06-13 15:06 ` Christopher J. PeBenito
0 siblings, 1 reply; 60+ messages in thread
From: Stephen Smalley @ 2007-06-13 14:31 UTC (permalink / raw)
To: selinux
Cc: James Morris, Eric Paris, Serge E. Hallyn,
Christopher J. PeBenito, Daniel J Walsh, Karl MacMillan
On Tue, 2007-06-12 at 17:12 -0400, Stephen Smalley wrote:
> On Tue, 2007-06-12 at 16:50 -0400, Stephen Smalley wrote:
> > On Tue, 2007-06-12 at 09:24 -0400, Stephen Smalley wrote:
> > > On Mon, 2007-06-11 at 15:55 -0400, Stephen Smalley wrote:
> > > > Extend SELinux to allow capabilities to be granted authoritatively.
> > > > Introduces a new cap_override access vector to indicate when the
> > > > secondary module (i.e. capability or dummy) check should be skipped.
> > > > Handle the new class gracefully even if the policy does not yet have
> > > > it defined.
> > >
> > > For people who want to test/experiment with this kernel patch, below is
> > > the policy patch I used to define the new class and permissions (it also
> > > includes the previously added memprotect class since that hasn't been
> > > added upstream yet). If you rebuild your base policy with this patch
> > > (e.g. grab the source package, add this patch, rebuild and reinstall),
> > > then you can subsequently create loadable policy modules that use the
> > > new cap_override permissions for testing.
> >
> > One thing to note is that the applicability of this approach under
> > targeted policy seems somewhat limited, as we have to ensure that a
> > DAC-unprivileged process in unconfined_t (like an ordinary user shell)
> > cannot ultimately gain unauthorized access to these capabilities granted
> > to another domain, but at present, confined domains are always at the
> > mercy of unconfined_t.
>
> I suppose we would need to ensure that even the unconfined domains are
> not given certain permissions (e.g. ptrace, sig*, setsched) to any
+noatsecure
> domain that is allowed these overrides. That should be equivalent to
> the same restrictions imposed by the file capabilities code.
Updated policy patch below, defines the new class and permissions,
and introduces an interface for allowing the cap_override permissions
that ensures that these domains are excluded from the set of domains
that can be controlled by unconfined domains.
Index: refpolicy/policy/flask/security_classes
===================================================================
--- refpolicy/policy/flask/security_classes (revision 2324)
+++ refpolicy/policy/flask/security_classes (working copy)
@@ -97,4 +97,8 @@
class dccp_socket
+class memprotect
+
+class cap_override
+
# FLASK
Index: refpolicy/policy/flask/access_vectors
===================================================================
--- refpolicy/policy/flask/access_vectors (revision 2324)
+++ refpolicy/policy/flask/access_vectors (working copy)
@@ -648,3 +648,47 @@
node_bind
name_connect
}
+
+class memprotect
+{
+ mmap_zero
+}
+
+class cap_override
+{
+ # The capabilities are defined in include/linux/capability.h
+ # Care should be taken to ensure that these are consistent with
+ # those definitions. (Order matters)
+
+ chown
+ dac_override
+ dac_read_search
+ fowner
+ fsetid
+ kill
+ setgid
+ setuid
+ setpcap
+ linux_immutable
+ net_bind_service
+ net_broadcast
+ net_admin
+ net_raw
+ ipc_lock
+ ipc_owner
+ sys_module
+ sys_rawio
+ sys_chroot
+ sys_ptrace
+ sys_pacct
+ sys_admin
+ sys_boot
+ sys_nice
+ sys_resource
+ sys_time
+ sys_tty_config
+ mknod
+ lease
+ audit_write
+ audit_control
+}
Index: refpolicy/policy/modules/kernel/domain.if
===================================================================
--- refpolicy/policy/modules/kernel/domain.if (revision 2324)
+++ refpolicy/policy/modules/kernel/domain.if (working copy)
@@ -1254,3 +1254,28 @@
typeattribute $1 can_change_object_identity;
typeattribute $1 set_curr_context;
')
+
+########################################
+## <summary>
+## Ability to override capabilities.
+## </summary>
+## <param name="domain">
+## <summary>
+## Domain allowed access.
+## </summary>
+## </param>
+## <param name="capabilities">
+## <summary>
+## Capabilities that can be overridden.
+## </summary>
+## </param>
+#
+interface(`domain_capoverride',`
+ gen_require(`
+ attribute capoverride_domain_type;
+ ')
+
+ typeattribute $1 capoverride_domain_type;
+
+ allow $1 self:cap_override $2;
+')
Index: refpolicy/policy/modules/kernel/domain.te
===================================================================
--- refpolicy/policy/modules/kernel/domain.te (revision 2324)
+++ refpolicy/policy/modules/kernel/domain.te (working copy)
@@ -15,6 +15,11 @@
# Domains that are unconfined
attribute unconfined_domain_type;
+# Domains that have capability overrides.
+attribute capoverride_domain_type;
+
+neverallow { domain -capoverride_domain_type } self:cap_override *;
+
# Domains that can set their current context
# (perform dynamic transitions)
attribute set_curr_context;
@@ -130,9 +135,12 @@
allow unconfined_domain_type domain:fd use;
allow unconfined_domain_type domain:fifo_file rw_file_perms;
-# Act upon any other process.
-allow unconfined_domain_type domain:process ~{ transition dyntransition execmem execstack execheap };
+# Act upon any other process that lacks capability overrides.
+allow unconfined_domain_type { domain -capoverride_domain_type }:process ~{ transition dyntransition execmem execstack execheap };
+# More limited access to domains with capability overrides.
+allow unconfined_domain_type capoverride_domain_type:process { signull getsched getpgid getattr };
+
# Create/access any System V IPC objects.
allow unconfined_domain_type domain:{ sem msgq shm } *;
allow unconfined_domain_type domain:msg { send receive };
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-13 14:31 ` Stephen Smalley
@ 2007-06-13 15:06 ` Christopher J. PeBenito
2007-06-13 15:28 ` Stephen Smalley
0 siblings, 1 reply; 60+ messages in thread
From: Christopher J. PeBenito @ 2007-06-13 15:06 UTC (permalink / raw)
To: Stephen Smalley
Cc: selinux, James Morris, Eric Paris, Serge E. Hallyn,
Daniel J Walsh, Karl MacMillan
On Wed, 2007-06-13 at 10:31 -0400, Stephen Smalley wrote:
> Updated policy patch below, defines the new class and permissions,
> and introduces an interface for allowing the cap_override permissions
> that ensures that these domains are excluded from the set of domains
> that can be controlled by unconfined domains.
[...]
> +interface(`domain_capoverride',`
I would probably call this domain_capability_override() or
domain_cap_override(), maybe even domain_authoritative_caps().
> + gen_require(`
> + attribute capoverride_domain_type;
> + ')
> +
> + typeattribute $1 capoverride_domain_type;
> +
> + allow $1 self:cap_override $2;
I think it would be better to just have the allow rule in the TE file.
Then you can put your cap_override and capability allow rules next to
each other and see more clearly which ones are being overridden and
which aren't.
> +')
--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-13 15:06 ` Christopher J. PeBenito
@ 2007-06-13 15:28 ` Stephen Smalley
2007-06-13 18:46 ` Christopher J. PeBenito
2007-06-13 19:10 ` Eric Paris
0 siblings, 2 replies; 60+ messages in thread
From: Stephen Smalley @ 2007-06-13 15:28 UTC (permalink / raw)
To: Christopher J. PeBenito
Cc: selinux, James Morris, Eric Paris, Serge E. Hallyn,
Daniel J Walsh, Karl MacMillan
On Wed, 2007-06-13 at 11:06 -0400, Christopher J. PeBenito wrote:
> On Wed, 2007-06-13 at 10:31 -0400, Stephen Smalley wrote:
> > Updated policy patch below, defines the new class and permissions,
> > and introduces an interface for allowing the cap_override permissions
> > that ensures that these domains are excluded from the set of domains
> > that can be controlled by unconfined domains.
>
> [...]
>
> > +interface(`domain_capoverride',`
>
> I would probably call this domain_capability_override() or
> domain_cap_override(), maybe even domain_authoritative_caps().
>
> > + gen_require(`
> > + attribute capoverride_domain_type;
> > + ')
> > +
> > + typeattribute $1 capoverride_domain_type;
> > +
> > + allow $1 self:cap_override $2;
>
> I think it would be better to just have the allow rule in the TE file.
> Then you can put your cap_override and capability allow rules next to
> each other and see more clearly which ones are being overridden and
> which aren't.
Ok, so you'd prefer the patch below?
BTW, one other issue that I noticed is that this has a side effect if I
grant capoverride to any of the unconfined domains (not that one should
do that, but still), because it seems that unconfined domains are
implicitly picking up permissions to self through the allow
unconfined_domain_type domain: rules. Seems like those should be
separated?
Index: refpolicy/policy/flask/security_classes
===================================================================
--- refpolicy/policy/flask/security_classes (revision 2324)
+++ refpolicy/policy/flask/security_classes (working copy)
@@ -97,4 +97,8 @@
class dccp_socket
+class memprotect
+
+class cap_override
+
# FLASK
Index: refpolicy/policy/flask/access_vectors
===================================================================
--- refpolicy/policy/flask/access_vectors (revision 2324)
+++ refpolicy/policy/flask/access_vectors (working copy)
@@ -648,3 +648,47 @@
node_bind
name_connect
}
+
+class memprotect
+{
+ mmap_zero
+}
+
+class cap_override
+{
+ # The capabilities are defined in include/linux/capability.h
+ # Care should be taken to ensure that these are consistent with
+ # those definitions. (Order matters)
+
+ chown
+ dac_override
+ dac_read_search
+ fowner
+ fsetid
+ kill
+ setgid
+ setuid
+ setpcap
+ linux_immutable
+ net_bind_service
+ net_broadcast
+ net_admin
+ net_raw
+ ipc_lock
+ ipc_owner
+ sys_module
+ sys_rawio
+ sys_chroot
+ sys_ptrace
+ sys_pacct
+ sys_admin
+ sys_boot
+ sys_nice
+ sys_resource
+ sys_time
+ sys_tty_config
+ mknod
+ lease
+ audit_write
+ audit_control
+}
Index: refpolicy/policy/modules/kernel/domain.if
===================================================================
--- refpolicy/policy/modules/kernel/domain.if (revision 2324)
+++ refpolicy/policy/modules/kernel/domain.if (working copy)
@@ -1254,3 +1254,21 @@
typeattribute $1 can_change_object_identity;
typeattribute $1 set_curr_context;
')
+
+########################################
+## <summary>
+## Ability to override capabilities.
+## </summary>
+## <param name="domain">
+## <summary>
+## Domain allowed to override capabilities.
+## </summary>
+## </param>
+#
+interface(`domain_cap_override',`
+ gen_require(`
+ attribute cap_override_domain_type;
+ ')
+
+ typeattribute $1 cap_override_domain_type;
+')
Index: refpolicy/policy/modules/kernel/domain.te
===================================================================
--- refpolicy/policy/modules/kernel/domain.te (revision 2324)
+++ refpolicy/policy/modules/kernel/domain.te (working copy)
@@ -15,6 +15,11 @@
# Domains that are unconfined
attribute unconfined_domain_type;
+# Domains that have capability overrides.
+attribute cap_override_domain_type;
+
+neverallow { domain -cap_override_domain_type } self:cap_override *;
+
# Domains that can set their current context
# (perform dynamic transitions)
attribute set_curr_context;
@@ -130,9 +135,12 @@
allow unconfined_domain_type domain:fd use;
allow unconfined_domain_type domain:fifo_file rw_file_perms;
-# Act upon any other process.
-allow unconfined_domain_type domain:process ~{ transition dyntransition execmem execstack execheap };
+# Act upon any other process that lacks capability overrides.
+allow unconfined_domain_type { domain -cap_override_domain_type }:process ~{ transition dyntransition execmem execstack execheap };
+# More limited access to domains with capability overrides.
+allow unconfined_domain_type cap_override_domain_type:process { signull getsched getpgid getattr };
+
# Create/access any System V IPC objects.
allow unconfined_domain_type domain:{ sem msgq shm } *;
allow unconfined_domain_type domain:msg { send receive };
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-13 15:28 ` Stephen Smalley
@ 2007-06-13 18:46 ` Christopher J. PeBenito
2007-06-13 19:20 ` Stephen Smalley
2007-06-13 19:10 ` Eric Paris
1 sibling, 1 reply; 60+ messages in thread
From: Christopher J. PeBenito @ 2007-06-13 18:46 UTC (permalink / raw)
To: Stephen Smalley
Cc: selinux, James Morris, Eric Paris, Serge E. Hallyn,
Daniel J Walsh, Karl MacMillan
On Wed, 2007-06-13 at 11:28 -0400, Stephen Smalley wrote:
> On Wed, 2007-06-13 at 11:06 -0400, Christopher J. PeBenito wrote:
> > On Wed, 2007-06-13 at 10:31 -0400, Stephen Smalley wrote:
> > > Updated policy patch below, defines the new class and permissions,
> > > and introduces an interface for allowing the cap_override permissions
> > > that ensures that these domains are excluded from the set of domains
> > > that can be controlled by unconfined domains.
> >
> > [...]
> >
> > > +interface(`domain_capoverride',`
> >
> > I would probably call this domain_capability_override() or
> > domain_cap_override(), maybe even domain_authoritative_caps().
> >
> > > + gen_require(`
> > > + attribute capoverride_domain_type;
> > > + ')
> > > +
> > > + typeattribute $1 capoverride_domain_type;
> > > +
> > > + allow $1 self:cap_override $2;
> >
> > I think it would be better to just have the allow rule in the TE file.
> > Then you can put your cap_override and capability allow rules next to
> > each other and see more clearly which ones are being overridden and
> > which aren't.
>
> Ok, so you'd prefer the patch below?
Looks good to me.
> BTW, one other issue that I noticed is that this has a side effect if I
> grant capoverride to any of the unconfined domains (not that one should
> do that, but still), because it seems that unconfined domains are
> implicitly picking up permissions to self through the allow
> unconfined_domain_type domain: rules. Seems like those should be
> separated?
I don't understand what the concern is, can you clarify? I see what you
mean about it picking up self permissions through domain, but I'm not
sure what permissions are in question.
> Index: refpolicy/policy/flask/security_classes
> ===================================================================
> --- refpolicy/policy/flask/security_classes (revision 2324)
> +++ refpolicy/policy/flask/security_classes (working copy)
> @@ -97,4 +97,8 @@
>
> class dccp_socket
>
> +class memprotect
> +
> +class cap_override
> +
> # FLASK
> Index: refpolicy/policy/flask/access_vectors
> ===================================================================
> --- refpolicy/policy/flask/access_vectors (revision 2324)
> +++ refpolicy/policy/flask/access_vectors (working copy)
> @@ -648,3 +648,47 @@
> node_bind
> name_connect
> }
> +
> +class memprotect
> +{
> + mmap_zero
> +}
> +
> +class cap_override
> +{
> + # The capabilities are defined in include/linux/capability.h
> + # Care should be taken to ensure that these are consistent with
> + # those definitions. (Order matters)
> +
> + chown
> + dac_override
> + dac_read_search
> + fowner
> + fsetid
> + kill
> + setgid
> + setuid
> + setpcap
> + linux_immutable
> + net_bind_service
> + net_broadcast
> + net_admin
> + net_raw
> + ipc_lock
> + ipc_owner
> + sys_module
> + sys_rawio
> + sys_chroot
> + sys_ptrace
> + sys_pacct
> + sys_admin
> + sys_boot
> + sys_nice
> + sys_resource
> + sys_time
> + sys_tty_config
> + mknod
> + lease
> + audit_write
> + audit_control
> +}
> Index: refpolicy/policy/modules/kernel/domain.if
> ===================================================================
> --- refpolicy/policy/modules/kernel/domain.if (revision 2324)
> +++ refpolicy/policy/modules/kernel/domain.if (working copy)
> @@ -1254,3 +1254,21 @@
> typeattribute $1 can_change_object_identity;
> typeattribute $1 set_curr_context;
> ')
> +
> +########################################
> +## <summary>
> +## Ability to override capabilities.
> +## </summary>
> +## <param name="domain">
> +## <summary>
> +## Domain allowed to override capabilities.
> +## </summary>
> +## </param>
> +#
> +interface(`domain_cap_override',`
> + gen_require(`
> + attribute cap_override_domain_type;
> + ')
> +
> + typeattribute $1 cap_override_domain_type;
> +')
> Index: refpolicy/policy/modules/kernel/domain.te
> ===================================================================
> --- refpolicy/policy/modules/kernel/domain.te (revision 2324)
> +++ refpolicy/policy/modules/kernel/domain.te (working copy)
> @@ -15,6 +15,11 @@
> # Domains that are unconfined
> attribute unconfined_domain_type;
>
> +# Domains that have capability overrides.
> +attribute cap_override_domain_type;
> +
> +neverallow { domain -cap_override_domain_type } self:cap_override *;
> +
> # Domains that can set their current context
> # (perform dynamic transitions)
> attribute set_curr_context;
> @@ -130,9 +135,12 @@
> allow unconfined_domain_type domain:fd use;
> allow unconfined_domain_type domain:fifo_file rw_file_perms;
>
> -# Act upon any other process.
> -allow unconfined_domain_type domain:process ~{ transition dyntransition execmem execstack execheap };
> +# Act upon any other process that lacks capability overrides.
> +allow unconfined_domain_type { domain -cap_override_domain_type }:process ~{ transition dyntransition execmem execstack execheap };
>
> +# More limited access to domains with capability overrides.
> +allow unconfined_domain_type cap_override_domain_type:process { signull getsched getpgid getattr };
> +
> # Create/access any System V IPC objects.
> allow unconfined_domain_type domain:{ sem msgq shm } *;
> allow unconfined_domain_type domain:msg { send receive };
>
--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-13 18:46 ` Christopher J. PeBenito
@ 2007-06-13 19:20 ` Stephen Smalley
2007-06-14 19:19 ` Christopher J. PeBenito
0 siblings, 1 reply; 60+ messages in thread
From: Stephen Smalley @ 2007-06-13 19:20 UTC (permalink / raw)
To: Christopher J. PeBenito
Cc: selinux, James Morris, Eric Paris, Serge E. Hallyn,
Daniel J Walsh, Karl MacMillan, Joshua Brindle
On Wed, 2007-06-13 at 14:46 -0400, Christopher J. PeBenito wrote:
> On Wed, 2007-06-13 at 11:28 -0400, Stephen Smalley wrote:
> > On Wed, 2007-06-13 at 11:06 -0400, Christopher J. PeBenito wrote:
> > > On Wed, 2007-06-13 at 10:31 -0400, Stephen Smalley wrote:
> > > > Updated policy patch below, defines the new class and permissions,
> > > > and introduces an interface for allowing the cap_override permissions
> > > > that ensures that these domains are excluded from the set of domains
> > > > that can be controlled by unconfined domains.
> > >
> > > [...]
> > >
> > > > +interface(`domain_capoverride',`
> > >
> > > I would probably call this domain_capability_override() or
> > > domain_cap_override(), maybe even domain_authoritative_caps().
> > >
> > > > + gen_require(`
> > > > + attribute capoverride_domain_type;
> > > > + ')
> > > > +
> > > > + typeattribute $1 capoverride_domain_type;
> > > > +
> > > > + allow $1 self:cap_override $2;
> > >
> > > I think it would be better to just have the allow rule in the TE file.
> > > Then you can put your cap_override and capability allow rules next to
> > > each other and see more clearly which ones are being overridden and
> > > which aren't.
> >
> > Ok, so you'd prefer the patch below?
>
> Looks good to me.
>
> > BTW, one other issue that I noticed is that this has a side effect if I
> > grant capoverride to any of the unconfined domains (not that one should
> > do that, but still), because it seems that unconfined domains are
> > implicitly picking up permissions to self through the allow
> > unconfined_domain_type domain: rules. Seems like those should be
> > separated?
>
> I don't understand what the concern is, can you clarify? I see what you
> mean about it picking up self permissions through domain, but I'm not
> sure what permissions are in question.
As a test case, I created and inserted a policy module that gave
unconfined_t the cap overrides, and immediately started getting denials
on the unconfined_t shell doing things like setpgid to its children,
because unconfined_t was then excluded from the usual allow rule by
virtue of being added to the attribute.
Any time we remove a permission from the list of permissions granted
from unconfined_domain_type to all other domains, we might lose it even
in the self case if we don't have a separate self rule.
I'm also wondering if the current idiom of using allow <domain>
self:process ~{ a b c }; isn't more confusing at this point than an
explicit enumeration of the permissions to be allowed; we keep adding
permissions that we don't want to allow by default. Or at least those
should be converted to a common macro/pattern so that we can more easily
add exceptions. The set complement and wildcard cases are also
problematic in their present implementation since they set all of the
other bits, not just the ones that are defined in that policy. Possibly
set complement and wildcard should be phased out altogether for
permission sets in allow rules, just as we phased them out for types.
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-13 19:20 ` Stephen Smalley
@ 2007-06-14 19:19 ` Christopher J. PeBenito
2007-06-15 11:50 ` Stephen Smalley
0 siblings, 1 reply; 60+ messages in thread
From: Christopher J. PeBenito @ 2007-06-14 19:19 UTC (permalink / raw)
To: Stephen Smalley
Cc: selinux, James Morris, Eric Paris, Serge E. Hallyn,
Daniel J Walsh, Karl MacMillan, Joshua Brindle
On Wed, 2007-06-13 at 15:20 -0400, Stephen Smalley wrote:
> On Wed, 2007-06-13 at 14:46 -0400, Christopher J. PeBenito wrote:
> > On Wed, 2007-06-13 at 11:28 -0400, Stephen Smalley wrote:
> > > BTW, one other issue that I noticed is that this has a side effect if I
> > > grant capoverride to any of the unconfined domains (not that one should
> > > do that, but still), because it seems that unconfined domains are
> > > implicitly picking up permissions to self through the allow
> > > unconfined_domain_type domain: rules. Seems like those should be
> > > separated?
> >
> > I don't understand what the concern is, can you clarify? I see what you
> > mean about it picking up self permissions through domain, but I'm not
> > sure what permissions are in question.
>
> As a test case, I created and inserted a policy module that gave
> unconfined_t the cap overrides, and immediately started getting denials
> on the unconfined_t shell doing things like setpgid to its children,
> because unconfined_t was then excluded from the usual allow rule by
> virtue of being added to the attribute.
>
> Any time we remove a permission from the list of permissions granted
> from unconfined_domain_type to all other domains, we might lose it even
> in the self case if we don't have a separate self rule.
Ok I understand. So we do need a self rule.
> I'm also wondering if the current idiom of using allow <domain>
> self:process ~{ a b c }; isn't more confusing at this point than an
> explicit enumeration of the permissions to be allowed; we keep adding
> permissions that we don't want to allow by default. Or at least those
> should be converted to a common macro/pattern so that we can more easily
> add exceptions.
We could have a macro for the exclusions, but I don't feel strongly
about it since there are 29 process perms and we're only excluding 4 or
5 perms, and that exclusion only repeats once.
> The set complement and wildcard cases are also
> problematic in their present implementation since they set all of the
> other bits, not just the ones that are defined in that policy. Possibly
> set complement and wildcard should be phased out altogether for
> permission sets in allow rules, just as we phased them out for types.
The wildcard is less interesting, as we already generate a macro that
has all defined permissions for each class since we needed that for
require blocks (see dbus_system_bus_unconfined() for an example).
--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-14 19:19 ` Christopher J. PeBenito
@ 2007-06-15 11:50 ` Stephen Smalley
0 siblings, 0 replies; 60+ messages in thread
From: Stephen Smalley @ 2007-06-15 11:50 UTC (permalink / raw)
To: Christopher J. PeBenito
Cc: selinux, James Morris, Eric Paris, Serge E. Hallyn,
Daniel J Walsh, Karl MacMillan, Joshua Brindle
On Thu, 2007-06-14 at 19:19 +0000, Christopher J. PeBenito wrote:
> On Wed, 2007-06-13 at 15:20 -0400, Stephen Smalley wrote:
> > On Wed, 2007-06-13 at 14:46 -0400, Christopher J. PeBenito wrote:
> > > On Wed, 2007-06-13 at 11:28 -0400, Stephen Smalley wrote:
> > > > BTW, one other issue that I noticed is that this has a side effect if I
> > > > grant capoverride to any of the unconfined domains (not that one should
> > > > do that, but still), because it seems that unconfined domains are
> > > > implicitly picking up permissions to self through the allow
> > > > unconfined_domain_type domain: rules. Seems like those should be
> > > > separated?
> > >
> > > I don't understand what the concern is, can you clarify? I see what you
> > > mean about it picking up self permissions through domain, but I'm not
> > > sure what permissions are in question.
> >
> > As a test case, I created and inserted a policy module that gave
> > unconfined_t the cap overrides, and immediately started getting denials
> > on the unconfined_t shell doing things like setpgid to its children,
> > because unconfined_t was then excluded from the usual allow rule by
> > virtue of being added to the attribute.
> >
> > Any time we remove a permission from the list of permissions granted
> > from unconfined_domain_type to all other domains, we might lose it even
> > in the self case if we don't have a separate self rule.
>
> Ok I understand. So we do need a self rule.
>
> > I'm also wondering if the current idiom of using allow <domain>
> > self:process ~{ a b c }; isn't more confusing at this point than an
> > explicit enumeration of the permissions to be allowed; we keep adding
> > permissions that we don't want to allow by default. Or at least those
> > should be converted to a common macro/pattern so that we can more easily
> > add exceptions.
>
> We could have a macro for the exclusions, but I don't feel strongly
> about it since there are 29 process perms and we're only excluding 4 or
> 5 perms, and that exclusion only repeats once.
I see ~{ ptrace setcurrent ... } pervasively throughout many .te files,
so my concern is not just within unconfined but being able to update all
users easily.
> > The set complement and wildcard cases are also
> > problematic in their present implementation since they set all of the
> > other bits, not just the ones that are defined in that policy. Possibly
> > set complement and wildcard should be phased out altogether for
> > permission sets in allow rules, just as we phased them out for types.
>
> The wildcard is less interesting, as we already generate a macro that
> has all defined permissions for each class since we needed that for
> require blocks (see dbus_system_bus_unconfined() for an example).
>
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-13 15:28 ` Stephen Smalley
2007-06-13 18:46 ` Christopher J. PeBenito
@ 2007-06-13 19:10 ` Eric Paris
2007-06-13 19:22 ` Stephen Smalley
1 sibling, 1 reply; 60+ messages in thread
From: Eric Paris @ 2007-06-13 19:10 UTC (permalink / raw)
To: Stephen Smalley
Cc: Christopher J. PeBenito, selinux, James Morris, Serge E. Hallyn,
Daniel J Walsh, Karl MacMillan
On 6/13/07, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On Wed, 2007-06-13 at 11:06 -0400, Christopher J. PeBenito wrote:
> > On Wed, 2007-06-13 at 10:31 -0400, Stephen Smalley wrote:
> > > Updated policy patch below, defines the new class and permissions,
> > > and introduces an interface for allowing the cap_override permissions
> > > that ensures that these domains are excluded from the set of domains
> > > that can be controlled by unconfined domains.
> >
> > [...]
> >
> > > +interface(`domain_capoverride',`
> >
> > I would probably call this domain_capability_override() or
> > domain_cap_override(), maybe even domain_authoritative_caps().
> >
> > > + gen_require(`
> > > + attribute capoverride_domain_type;
> > > + ')
> > > +
> > > + typeattribute $1 capoverride_domain_type;
> > > +
> > > + allow $1 self:cap_override $2;
> >
> > I think it would be better to just have the allow rule in the TE file.
> > Then you can put your cap_override and capability allow rules next to
> > each other and see more clearly which ones are being overridden and
> > which aren't.
>
> Ok, so you'd prefer the patch below?
> BTW, one other issue that I noticed is that this has a side effect if I
> grant capoverride to any of the unconfined domains (not that one should
> do that, but still), because it seems that unconfined domains are
> implicitly picking up permissions to self through the allow
> unconfined_domain_type domain: rules. Seems like those should be
> separated?
>
> Index: refpolicy/policy/flask/security_classes
> ===================================================================
> --- refpolicy/policy/flask/security_classes (revision 2324)
> +++ refpolicy/policy/flask/security_classes (working copy)
> @@ -97,4 +97,8 @@
>
> class dccp_socket
>
> +class memprotect
> +
> +class cap_override
> +
> # FLASK
Looks good to me, thanks for putting in my classes and perms too, I'm
swamped still for a couple more days, I'm really sorry about that.....
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-13 19:10 ` Eric Paris
@ 2007-06-13 19:22 ` Stephen Smalley
2007-06-13 19:50 ` Daniel J Walsh
0 siblings, 1 reply; 60+ messages in thread
From: Stephen Smalley @ 2007-06-13 19:22 UTC (permalink / raw)
To: Eric Paris
Cc: Christopher J. PeBenito, selinux, James Morris, Serge E. Hallyn,
Daniel J Walsh, Karl MacMillan
On Wed, 2007-06-13 at 15:10 -0400, Eric Paris wrote:
> On 6/13/07, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > On Wed, 2007-06-13 at 11:06 -0400, Christopher J. PeBenito wrote:
> > > On Wed, 2007-06-13 at 10:31 -0400, Stephen Smalley wrote:
> > > > Updated policy patch below, defines the new class and permissions,
> > > > and introduces an interface for allowing the cap_override permissions
> > > > that ensures that these domains are excluded from the set of domains
> > > > that can be controlled by unconfined domains.
> > >
> > > [...]
> > >
> > > > +interface(`domain_capoverride',`
> > >
> > > I would probably call this domain_capability_override() or
> > > domain_cap_override(), maybe even domain_authoritative_caps().
> > >
> > > > + gen_require(`
> > > > + attribute capoverride_domain_type;
> > > > + ')
> > > > +
> > > > + typeattribute $1 capoverride_domain_type;
> > > > +
> > > > + allow $1 self:cap_override $2;
> > >
> > > I think it would be better to just have the allow rule in the TE file.
> > > Then you can put your cap_override and capability allow rules next to
> > > each other and see more clearly which ones are being overridden and
> > > which aren't.
> >
> > Ok, so you'd prefer the patch below?
> > BTW, one other issue that I noticed is that this has a side effect if I
> > grant capoverride to any of the unconfined domains (not that one should
> > do that, but still), because it seems that unconfined domains are
> > implicitly picking up permissions to self through the allow
> > unconfined_domain_type domain: rules. Seems like those should be
> > separated?
> >
> > Index: refpolicy/policy/flask/security_classes
> > ===================================================================
> > --- refpolicy/policy/flask/security_classes (revision 2324)
> > +++ refpolicy/policy/flask/security_classes (working copy)
> > @@ -97,4 +97,8 @@
> >
> > class dccp_socket
> >
> > +class memprotect
> > +
> > +class cap_override
> > +
> > # FLASK
>
> Looks good to me, thanks for putting in my classes and perms too, I'm
> swamped still for a couple more days, I'm really sorry about that.....
We'll need to introduce an interface for memprotect:mmap_zero as well to
allow it when needed, along with a corresponding type attribute and
neverallow rule to ensure that all such uses are flagged as such.
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-13 19:22 ` Stephen Smalley
@ 2007-06-13 19:50 ` Daniel J Walsh
2007-06-13 20:00 ` Stephen Smalley
0 siblings, 1 reply; 60+ messages in thread
From: Daniel J Walsh @ 2007-06-13 19:50 UTC (permalink / raw)
To: Stephen Smalley
Cc: Eric Paris, Christopher J. PeBenito, selinux, James Morris,
Serge E. Hallyn, Karl MacMillan
Stephen Smalley wrote:
> On Wed, 2007-06-13 at 15:10 -0400, Eric Paris wrote:
>
>> On 6/13/07, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>>
>>> On Wed, 2007-06-13 at 11:06 -0400, Christopher J. PeBenito wrote:
>>>
>>>> On Wed, 2007-06-13 at 10:31 -0400, Stephen Smalley wrote:
>>>>
>>>>> Updated policy patch below, defines the new class and permissions,
>>>>> and introduces an interface for allowing the cap_override permissions
>>>>> that ensures that these domains are excluded from the set of domains
>>>>> that can be controlled by unconfined domains.
>>>>>
>>>> [...]
>>>>
>>>>
>>>>> +interface(`domain_capoverride',`
>>>>>
>>>> I would probably call this domain_capability_override() or
>>>> domain_cap_override(), maybe even domain_authoritative_caps().
>>>>
>>>>
>>>>> + gen_require(`
>>>>> + attribute capoverride_domain_type;
>>>>> + ')
>>>>> +
>>>>> + typeattribute $1 capoverride_domain_type;
>>>>> +
>>>>> + allow $1 self:cap_override $2;
>>>>>
>>>> I think it would be better to just have the allow rule in the TE file.
>>>> Then you can put your cap_override and capability allow rules next to
>>>> each other and see more clearly which ones are being overridden and
>>>> which aren't.
>>>>
>>> Ok, so you'd prefer the patch below?
>>> BTW, one other issue that I noticed is that this has a side effect if I
>>> grant capoverride to any of the unconfined domains (not that one should
>>> do that, but still), because it seems that unconfined domains are
>>> implicitly picking up permissions to self through the allow
>>> unconfined_domain_type domain: rules. Seems like those should be
>>> separated?
>>>
>>> Index: refpolicy/policy/flask/security_classes
>>> ===================================================================
>>> --- refpolicy/policy/flask/security_classes (revision 2324)
>>> +++ refpolicy/policy/flask/security_classes (working copy)
>>> @@ -97,4 +97,8 @@
>>>
>>> class dccp_socket
>>>
>>> +class memprotect
>>> +
>>> +class cap_override
>>> +
>>> # FLASK
>>>
>> Looks good to me, thanks for putting in my classes and perms too, I'm
>> swamped still for a couple more days, I'm really sorry about that.....
>>
>
> We'll need to introduce an interface for memprotect:mmap_zero as well to
> allow it when needed, along with a corresponding type attribute and
> neverallow rule to ensure that all such uses are flagged as such.
>
>
These changes prevent a domain transition on targeted policy from
initrc_t which is an unconfined_domain to a domain that has
cap_override, which might be unexpected. We might also want to add a
dontaudit unconfined_domain capoverride_domain_type:process ptrace;
Otherwise killall/pidof will generate avc messages.
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-13 19:50 ` Daniel J Walsh
@ 2007-06-13 20:00 ` Stephen Smalley
2007-06-13 20:22 ` Daniel J Walsh
0 siblings, 1 reply; 60+ messages in thread
From: Stephen Smalley @ 2007-06-13 20:00 UTC (permalink / raw)
To: Daniel J Walsh
Cc: Eric Paris, Christopher J. PeBenito, selinux, James Morris,
Serge E. Hallyn, Karl MacMillan
On Wed, 2007-06-13 at 15:50 -0400, Daniel J Walsh wrote:
> Stephen Smalley wrote:
> > On Wed, 2007-06-13 at 15:10 -0400, Eric Paris wrote:
> >
> >> On 6/13/07, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> >>
> >>> On Wed, 2007-06-13 at 11:06 -0400, Christopher J. PeBenito wrote:
> >>>
> >>>> On Wed, 2007-06-13 at 10:31 -0400, Stephen Smalley wrote:
> >>>>
> >>>>> Updated policy patch below, defines the new class and permissions,
> >>>>> and introduces an interface for allowing the cap_override permissions
> >>>>> that ensures that these domains are excluded from the set of domains
> >>>>> that can be controlled by unconfined domains.
> >>>>>
> >>>> [...]
> >>>>
> >>>>
> >>>>> +interface(`domain_capoverride',`
> >>>>>
> >>>> I would probably call this domain_capability_override() or
> >>>> domain_cap_override(), maybe even domain_authoritative_caps().
> >>>>
> >>>>
> >>>>> + gen_require(`
> >>>>> + attribute capoverride_domain_type;
> >>>>> + ')
> >>>>> +
> >>>>> + typeattribute $1 capoverride_domain_type;
> >>>>> +
> >>>>> + allow $1 self:cap_override $2;
> >>>>>
> >>>> I think it would be better to just have the allow rule in the TE file.
> >>>> Then you can put your cap_override and capability allow rules next to
> >>>> each other and see more clearly which ones are being overridden and
> >>>> which aren't.
> >>>>
> >>> Ok, so you'd prefer the patch below?
> >>> BTW, one other issue that I noticed is that this has a side effect if I
> >>> grant capoverride to any of the unconfined domains (not that one should
> >>> do that, but still), because it seems that unconfined domains are
> >>> implicitly picking up permissions to self through the allow
> >>> unconfined_domain_type domain: rules. Seems like those should be
> >>> separated?
> >>>
> >>> Index: refpolicy/policy/flask/security_classes
> >>> ===================================================================
> >>> --- refpolicy/policy/flask/security_classes (revision 2324)
> >>> +++ refpolicy/policy/flask/security_classes (working copy)
> >>> @@ -97,4 +97,8 @@
> >>>
> >>> class dccp_socket
> >>>
> >>> +class memprotect
> >>> +
> >>> +class cap_override
> >>> +
> >>> # FLASK
> >>>
> >> Looks good to me, thanks for putting in my classes and perms too, I'm
> >> swamped still for a couple more days, I'm really sorry about that.....
> >>
> >
> > We'll need to introduce an interface for memprotect:mmap_zero as well to
> > allow it when needed, along with a corresponding type attribute and
> > neverallow rule to ensure that all such uses are flagged as such.
> >
> >
> These changes prevent a domain transition on targeted policy from
> initrc_t which is an unconfined_domain to a domain that has
> cap_override, which might be unexpected.
I don't understand that - nothing in my patch alters transition rules
(transition was already excluded from that rule via the set complement
(~)). What permission was denied? Domain transitions from unconfined
domains always have needed to be explicitly authorized.
> We might also want to add a
>
> dontaudit unconfined_domain capoverride_domain_type:process ptrace;
>
> Otherwise killall/pidof will generate avc messages.
Ok - note though that I renamed the attribute to
cap_override_domain_type in the final version of the patch for
consistency (cap_override rather than capoverride) throughout.
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-13 20:00 ` Stephen Smalley
@ 2007-06-13 20:22 ` Daniel J Walsh
0 siblings, 0 replies; 60+ messages in thread
From: Daniel J Walsh @ 2007-06-13 20:22 UTC (permalink / raw)
To: Stephen Smalley
Cc: Eric Paris, Christopher J. PeBenito, selinux, James Morris,
Serge E. Hallyn, Karl MacMillan
Stephen Smalley wrote:
> On Wed, 2007-06-13 at 15:50 -0400, Daniel J Walsh wrote:
>
>> Stephen Smalley wrote:
>>
>>> On Wed, 2007-06-13 at 15:10 -0400, Eric Paris wrote:
>>>
>>>
>>>> On 6/13/07, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>>>>
>>>>
>>>>> On Wed, 2007-06-13 at 11:06 -0400, Christopher J. PeBenito wrote:
>>>>>
>>>>>
>>>>>> On Wed, 2007-06-13 at 10:31 -0400, Stephen Smalley wrote:
>>>>>>
>>>>>>
>>>>>>> Updated policy patch below, defines the new class and permissions,
>>>>>>> and introduces an interface for allowing the cap_override permissions
>>>>>>> that ensures that these domains are excluded from the set of domains
>>>>>>> that can be controlled by unconfined domains.
>>>>>>>
>>>>>>>
>>>>>> [...]
>>>>>>
>>>>>>
>>>>>>
>>>>>>> +interface(`domain_capoverride',`
>>>>>>>
>>>>>>>
>>>>>> I would probably call this domain_capability_override() or
>>>>>> domain_cap_override(), maybe even domain_authoritative_caps().
>>>>>>
>>>>>>
>>>>>>
>>>>>>> + gen_require(`
>>>>>>> + attribute capoverride_domain_type;
>>>>>>> + ')
>>>>>>> +
>>>>>>> + typeattribute $1 capoverride_domain_type;
>>>>>>> +
>>>>>>> + allow $1 self:cap_override $2;
>>>>>>>
>>>>>>>
>>>>>> I think it would be better to just have the allow rule in the TE file.
>>>>>> Then you can put your cap_override and capability allow rules next to
>>>>>> each other and see more clearly which ones are being overridden and
>>>>>> which aren't.
>>>>>>
>>>>>>
>>>>> Ok, so you'd prefer the patch below?
>>>>> BTW, one other issue that I noticed is that this has a side effect if I
>>>>> grant capoverride to any of the unconfined domains (not that one should
>>>>> do that, but still), because it seems that unconfined domains are
>>>>> implicitly picking up permissions to self through the allow
>>>>> unconfined_domain_type domain: rules. Seems like those should be
>>>>> separated?
>>>>>
>>>>> Index: refpolicy/policy/flask/security_classes
>>>>> ===================================================================
>>>>> --- refpolicy/policy/flask/security_classes (revision 2324)
>>>>> +++ refpolicy/policy/flask/security_classes (working copy)
>>>>> @@ -97,4 +97,8 @@
>>>>>
>>>>> class dccp_socket
>>>>>
>>>>> +class memprotect
>>>>> +
>>>>> +class cap_override
>>>>> +
>>>>> # FLASK
>>>>>
>>>>>
>>>> Looks good to me, thanks for putting in my classes and perms too, I'm
>>>> swamped still for a couple more days, I'm really sorry about that.....
>>>>
>>>>
>>> We'll need to introduce an interface for memprotect:mmap_zero as well to
>>> allow it when needed, along with a corresponding type attribute and
>>> neverallow rule to ensure that all such uses are flagged as such.
>>>
>>>
>>>
>> These changes prevent a domain transition on targeted policy from
>> initrc_t which is an unconfined_domain to a domain that has
>> cap_override, which might be unexpected.
>>
>
> I don't understand that - nothing in my patch alters transition rules
> (transition was already excluded from that rule via the set complement
> (~)). What permission was denied? Domain transitions from unconfined
> domains always have needed to be explicitly authorized.
>
Ok, nevermind, I thought I read this as a neverallow.
>
>> We might also want to add a
>>
>> dontaudit unconfined_domain capoverride_domain_type:process ptrace;
>>
>> Otherwise killall/pidof will generate avc messages.
>>
>
> Ok - note though that I renamed the attribute to
> cap_override_domain_type in the final version of the patch for
> consistency (cap_override rather than capoverride) throughout.
>
>
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-11 19:55 [RFC][PATCH] selinux: enable authoritative granting of capabilities Stephen Smalley
` (3 preceding siblings ...)
2007-06-12 13:24 ` Stephen Smalley
@ 2007-06-12 13:32 ` Stephen Smalley
2007-06-14 15:40 ` Chad Sellers
4 siblings, 1 reply; 60+ messages in thread
From: Stephen Smalley @ 2007-06-12 13:32 UTC (permalink / raw)
To: selinux; +Cc: James Morris, Eric Paris, Serge E. Hallyn
On Mon, 2007-06-11 at 15:55 -0400, Stephen Smalley wrote:
> Extend SELinux to allow capabilities to be granted authoritatively.
> Introduces a new cap_override access vector to indicate when the
> secondary module (i.e. capability or dummy) check should be skipped.
> Handle the new class gracefully even if the policy does not yet have
> it defined.
Ah, I realized that this has the same issue in permissive mode as the
get_user_sids code - we don't want to arbitrarily allow these
dac_override permissions in permissive mode (otherwise setenforce 0
turns off DAC as well), so the following patch should be applied on top:
diff -u b/security/selinux/hooks.c b/security/selinux/hooks.c
--- b/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -1424,7 +1424,7 @@
int rc;
rc = avc_has_perm_noaudit(sid, sid, SECCLASS_CAP_OVERRIDE,
- CAP_TO_MASK(cap), 0, NULL);
+ CAP_TO_MASK(cap), AVC_STRICT, NULL);
if (rc) {
rc = secondary_ops->capable(tsk, cap);
if (rc)
I'll fold that into the base patch for submission.
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-12 13:32 ` Stephen Smalley
@ 2007-06-14 15:40 ` Chad Sellers
2007-06-14 15:55 ` Stephen Smalley
2007-06-14 15:55 ` Karl MacMillan
0 siblings, 2 replies; 60+ messages in thread
From: Chad Sellers @ 2007-06-14 15:40 UTC (permalink / raw)
To: Stephen Smalley, selinux; +Cc: James Morris, Eric Paris, Serge E. Hallyn
On 6/12/07 9:32 AM, "Stephen Smalley" <sds@tycho.nsa.gov> wrote:
> On Mon, 2007-06-11 at 15:55 -0400, Stephen Smalley wrote:
>> Extend SELinux to allow capabilities to be granted authoritatively.
>> Introduces a new cap_override access vector to indicate when the
>> secondary module (i.e. capability or dummy) check should be skipped.
>> Handle the new class gracefully even if the policy does not yet have
>> it defined.
>
> Ah, I realized that this has the same issue in permissive mode as the
> get_user_sids code - we don't want to arbitrarily allow these
> dac_override permissions in permissive mode (otherwise setenforce 0
> turns off DAC as well), so the following patch should be applied on top:
>
> diff -u b/security/selinux/hooks.c b/security/selinux/hooks.c
> --- b/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -1424,7 +1424,7 @@
> int rc;
>
> rc = avc_has_perm_noaudit(sid, sid, SECCLASS_CAP_OVERRIDE,
> - CAP_TO_MASK(cap), 0, NULL);
> + CAP_TO_MASK(cap), AVC_STRICT, NULL);
> if (rc) {
> rc = secondary_ops->capable(tsk, cap);
> if (rc)
>
> I'll fold that into the base patch for submission.
This certainly makes the permissive case better than the original patch, but
you're still opening up a new vector for escalation of privilege when
SELinux access controls aren't enforcing. At the very least, policy authors
are going to have to be really careful with this, as it's easy to shoot
yourself in the foot in permissive. One example scenario of escalation:
A domain is granted cap_override:dac_override in policy. The system is
running in permissive mode. In permissive mode, the only thing that protects
the policy from being reloaded is DAC permissions, which the policy has
granted the domain the ability to override. So, the domain loads a new
policy which grants it cap_override:*. This means that in permissive
dac_override can easily get you all capabilities. Also, note that the same
scenario can be constructed without the original allow rule using a
capability shedding scenario.
I realize that there are already other scenarios where a program can use
dac_override to escalate to further capabilities. My point is that we seem
to be opening up a new attack vector here.
Thanks,
Chad
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-14 15:40 ` Chad Sellers
@ 2007-06-14 15:55 ` Stephen Smalley
2007-06-14 16:03 ` Stephen Smalley
2007-06-14 15:55 ` Karl MacMillan
1 sibling, 1 reply; 60+ messages in thread
From: Stephen Smalley @ 2007-06-14 15:55 UTC (permalink / raw)
To: Chad Sellers; +Cc: selinux, James Morris, Eric Paris, Serge E. Hallyn
On Thu, 2007-06-14 at 11:40 -0400, Chad Sellers wrote:
> On 6/12/07 9:32 AM, "Stephen Smalley" <sds@tycho.nsa.gov> wrote:
>
> > On Mon, 2007-06-11 at 15:55 -0400, Stephen Smalley wrote:
> >> Extend SELinux to allow capabilities to be granted authoritatively.
> >> Introduces a new cap_override access vector to indicate when the
> >> secondary module (i.e. capability or dummy) check should be skipped.
> >> Handle the new class gracefully even if the policy does not yet have
> >> it defined.
> >
> > Ah, I realized that this has the same issue in permissive mode as the
> > get_user_sids code - we don't want to arbitrarily allow these
> > dac_override permissions in permissive mode (otherwise setenforce 0
> > turns off DAC as well), so the following patch should be applied on top:
> >
> > diff -u b/security/selinux/hooks.c b/security/selinux/hooks.c
> > --- b/security/selinux/hooks.c
> > +++ b/security/selinux/hooks.c
> > @@ -1424,7 +1424,7 @@
> > int rc;
> >
> > rc = avc_has_perm_noaudit(sid, sid, SECCLASS_CAP_OVERRIDE,
> > - CAP_TO_MASK(cap), 0, NULL);
> > + CAP_TO_MASK(cap), AVC_STRICT, NULL);
> > if (rc) {
> > rc = secondary_ops->capable(tsk, cap);
> > if (rc)
> >
> > I'll fold that into the base patch for submission.
>
> This certainly makes the permissive case better than the original patch, but
> you're still opening up a new vector for escalation of privilege when
> SELinux access controls aren't enforcing. At the very least, policy authors
> are going to have to be really careful with this, as it's easy to shoot
> yourself in the foot in permissive. One example scenario of escalation:
>
> A domain is granted cap_override:dac_override in policy. The system is
> running in permissive mode. In permissive mode, the only thing that protects
> the policy from being reloaded is DAC permissions, which the policy has
> granted the domain the ability to override. So, the domain loads a new
> policy which grants it cap_override:*. This means that in permissive
> dac_override can easily get you all capabilities. Also, note that the same
> scenario can be constructed without the original allow rule using a
> capability shedding scenario.
>
> I realize that there are already other scenarios where a program can use
> dac_override to escalate to further capabilities. My point is that we seem
> to be opening up a new attack vector here.
Actually, we don't want the cap_overrides to take affect at all under
permissive mode, since permissive mode is generally about avoiding side
effects from SELinux permission checks and we lose any inter-domain
protection in permissive mode (thus unprivileged domain could take
control of domain with cap_overrides). So we would need to restrict the
override logic to enforcing mode only.
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-14 15:55 ` Stephen Smalley
@ 2007-06-14 16:03 ` Stephen Smalley
2007-06-14 16:13 ` Karl MacMillan
2007-06-14 16:52 ` James Morris
0 siblings, 2 replies; 60+ messages in thread
From: Stephen Smalley @ 2007-06-14 16:03 UTC (permalink / raw)
To: Chad Sellers; +Cc: selinux, James Morris, Eric Paris, Serge E. Hallyn
On Thu, 2007-06-14 at 11:55 -0400, Stephen Smalley wrote:
> On Thu, 2007-06-14 at 11:40 -0400, Chad Sellers wrote:
> > On 6/12/07 9:32 AM, "Stephen Smalley" <sds@tycho.nsa.gov> wrote:
> >
> > > On Mon, 2007-06-11 at 15:55 -0400, Stephen Smalley wrote:
> > >> Extend SELinux to allow capabilities to be granted authoritatively.
> > >> Introduces a new cap_override access vector to indicate when the
> > >> secondary module (i.e. capability or dummy) check should be skipped.
> > >> Handle the new class gracefully even if the policy does not yet have
> > >> it defined.
> > >
> > > Ah, I realized that this has the same issue in permissive mode as the
> > > get_user_sids code - we don't want to arbitrarily allow these
> > > dac_override permissions in permissive mode (otherwise setenforce 0
> > > turns off DAC as well), so the following patch should be applied on top:
> > >
> > > diff -u b/security/selinux/hooks.c b/security/selinux/hooks.c
> > > --- b/security/selinux/hooks.c
> > > +++ b/security/selinux/hooks.c
> > > @@ -1424,7 +1424,7 @@
> > > int rc;
> > >
> > > rc = avc_has_perm_noaudit(sid, sid, SECCLASS_CAP_OVERRIDE,
> > > - CAP_TO_MASK(cap), 0, NULL);
> > > + CAP_TO_MASK(cap), AVC_STRICT, NULL);
> > > if (rc) {
> > > rc = secondary_ops->capable(tsk, cap);
> > > if (rc)
> > >
> > > I'll fold that into the base patch for submission.
> >
> > This certainly makes the permissive case better than the original patch, but
> > you're still opening up a new vector for escalation of privilege when
> > SELinux access controls aren't enforcing. At the very least, policy authors
> > are going to have to be really careful with this, as it's easy to shoot
> > yourself in the foot in permissive. One example scenario of escalation:
> >
> > A domain is granted cap_override:dac_override in policy. The system is
> > running in permissive mode. In permissive mode, the only thing that protects
> > the policy from being reloaded is DAC permissions, which the policy has
> > granted the domain the ability to override. So, the domain loads a new
> > policy which grants it cap_override:*. This means that in permissive
> > dac_override can easily get you all capabilities. Also, note that the same
> > scenario can be constructed without the original allow rule using a
> > capability shedding scenario.
> >
> > I realize that there are already other scenarios where a program can use
> > dac_override to escalate to further capabilities. My point is that we seem
> > to be opening up a new attack vector here.
>
> Actually, we don't want the cap_overrides to take affect at all under
> permissive mode, since permissive mode is generally about avoiding side
> effects from SELinux permission checks and we lose any inter-domain
> protection in permissive mode (thus unprivileged domain could take
> control of domain with cap_overrides). So we would need to restrict the
> override logic to enforcing mode only.
Like so:
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 4b0ecfd..73cb235 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -1419,12 +1419,20 @@ static void selinux_capset_set(struct task_struct *target, kernel_cap_t *effecti
static int selinux_capable(struct task_struct *tsk, int cap)
{
+ struct task_security_struct *tsec = tsk->security;
+ u32 sid = tsec->sid;
int rc;
+ if (selinux_enforcing) {
+ rc = avc_has_perm_noaudit(sid, sid, SECCLASS_CAP_OVERRIDE,
+ CAP_TO_MASK(cap), AVC_STRICT, NULL);
+ if (!rc)
+ goto out;
+ }
rc = secondary_ops->capable(tsk, cap);
if (rc)
return rc;
-
+out:
return task_has_capability(tsk,cap);
}
diff --git a/security/selinux/include/av_inherit.h b/security/selinux/include/av_inherit.h
diff --git a/security/selinux/include/av_perm_to_string.h b/security/selinux/include/av_perm_to_string.h
index 049bf69..fc19a4d 100644
--- a/security/selinux/include/av_perm_to_string.h
+++ b/security/selinux/include/av_perm_to_string.h
@@ -159,3 +159,34 @@
S_(SECCLASS_DCCP_SOCKET, DCCP_SOCKET__NODE_BIND, "node_bind")
S_(SECCLASS_DCCP_SOCKET, DCCP_SOCKET__NAME_CONNECT, "name_connect")
S_(SECCLASS_MEMPROTECT, MEMPROTECT__MMAP_ZERO, "mmap_zero")
+ S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__CHOWN, "chown")
+ S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__DAC_OVERRIDE, "dac_override")
+ S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__DAC_READ_SEARCH, "dac_read_search")
+ S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__FOWNER, "fowner")
+ S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__FSETID, "fsetid")
+ S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__KILL, "kill")
+ S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__SETGID, "setgid")
+ S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__SETUID, "setuid")
+ S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__SETPCAP, "setpcap")
+ S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__LINUX_IMMUTABLE, "linux_immutable")
+ S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__NET_BIND_SERVICE, "net_bind_service")
+ S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__NET_BROADCAST, "net_broadcast")
+ S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__NET_ADMIN, "net_admin")
+ S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__NET_RAW, "net_raw")
+ S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__IPC_LOCK, "ipc_lock")
+ S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__IPC_OWNER, "ipc_owner")
+ S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__SYS_MODULE, "sys_module")
+ S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__SYS_RAWIO, "sys_rawio")
+ S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__SYS_CHROOT, "sys_chroot")
+ S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__SYS_PTRACE, "sys_ptrace")
+ S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__SYS_PACCT, "sys_pacct")
+ S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__SYS_ADMIN, "sys_admin")
+ S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__SYS_BOOT, "sys_boot")
+ S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__SYS_NICE, "sys_nice")
+ S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__SYS_RESOURCE, "sys_resource")
+ S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__SYS_TIME, "sys_time")
+ S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__SYS_TTY_CONFIG, "sys_tty_config")
+ S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__MKNOD, "mknod")
+ S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__LEASE, "lease")
+ S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__AUDIT_WRITE, "audit_write")
+ S_(SECCLASS_CAP_OVERRIDE, CAP_OVERRIDE__AUDIT_CONTROL, "audit_control")
diff --git a/security/selinux/include/av_permissions.h b/security/selinux/include/av_permissions.h
index eda89a2..b5f01a1 100644
--- a/security/selinux/include/av_permissions.h
+++ b/security/selinux/include/av_permissions.h
@@ -824,3 +824,34 @@
#define DCCP_SOCKET__NODE_BIND 0x00400000UL
#define DCCP_SOCKET__NAME_CONNECT 0x00800000UL
#define MEMPROTECT__MMAP_ZERO 0x00000001UL
+#define CAP_OVERRIDE__CHOWN 0x00000001UL
+#define CAP_OVERRIDE__DAC_OVERRIDE 0x00000002UL
+#define CAP_OVERRIDE__DAC_READ_SEARCH 0x00000004UL
+#define CAP_OVERRIDE__FOWNER 0x00000008UL
+#define CAP_OVERRIDE__FSETID 0x00000010UL
+#define CAP_OVERRIDE__KILL 0x00000020UL
+#define CAP_OVERRIDE__SETGID 0x00000040UL
+#define CAP_OVERRIDE__SETUID 0x00000080UL
+#define CAP_OVERRIDE__SETPCAP 0x00000100UL
+#define CAP_OVERRIDE__LINUX_IMMUTABLE 0x00000200UL
+#define CAP_OVERRIDE__NET_BIND_SERVICE 0x00000400UL
+#define CAP_OVERRIDE__NET_BROADCAST 0x00000800UL
+#define CAP_OVERRIDE__NET_ADMIN 0x00001000UL
+#define CAP_OVERRIDE__NET_RAW 0x00002000UL
+#define CAP_OVERRIDE__IPC_LOCK 0x00004000UL
+#define CAP_OVERRIDE__IPC_OWNER 0x00008000UL
+#define CAP_OVERRIDE__SYS_MODULE 0x00010000UL
+#define CAP_OVERRIDE__SYS_RAWIO 0x00020000UL
+#define CAP_OVERRIDE__SYS_CHROOT 0x00040000UL
+#define CAP_OVERRIDE__SYS_PTRACE 0x00080000UL
+#define CAP_OVERRIDE__SYS_PACCT 0x00100000UL
+#define CAP_OVERRIDE__SYS_ADMIN 0x00200000UL
+#define CAP_OVERRIDE__SYS_BOOT 0x00400000UL
+#define CAP_OVERRIDE__SYS_NICE 0x00800000UL
+#define CAP_OVERRIDE__SYS_RESOURCE 0x01000000UL
+#define CAP_OVERRIDE__SYS_TIME 0x02000000UL
+#define CAP_OVERRIDE__SYS_TTY_CONFIG 0x04000000UL
+#define CAP_OVERRIDE__MKNOD 0x08000000UL
+#define CAP_OVERRIDE__LEASE 0x10000000UL
+#define CAP_OVERRIDE__AUDIT_WRITE 0x20000000UL
+#define CAP_OVERRIDE__AUDIT_CONTROL 0x40000000UL
diff --git a/security/selinux/include/class_to_string.h b/security/selinux/include/class_to_string.h
index e77de0e..442a188 100644
--- a/security/selinux/include/class_to_string.h
+++ b/security/selinux/include/class_to_string.h
@@ -64,3 +64,4 @@
S_(NULL)
S_("dccp_socket")
S_("memprotect")
+ S_("cap_override")
diff --git a/security/selinux/include/common_perm_to_string.h b/security/selinux/include/common_perm_to_string.h
diff --git a/security/selinux/include/flask.h b/security/selinux/include/flask.h
index a9c2b20..ab1b861 100644
--- a/security/selinux/include/flask.h
+++ b/security/selinux/include/flask.h
@@ -50,6 +50,7 @@
#define SECCLASS_KEY 58
#define SECCLASS_DCCP_SOCKET 60
#define SECCLASS_MEMPROTECT 61
+#define SECCLASS_CAP_OVERRIDE 62
/*
* Security identifier indices for initial entities
diff --git a/security/selinux/include/initial_sid_to_string.h b/security/selinux/include/initial_sid_to_string.h
diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
index b5f017f..d16c809 100644
--- a/security/selinux/ss/services.c
+++ b/security/selinux/ss/services.c
@@ -305,13 +305,6 @@ static int context_struct_compute_av(struct context *scontext,
tclass <= SECCLASS_NETLINK_DNRT_SOCKET)
tclass = SECCLASS_NETLINK_SOCKET;
- if (!tclass || tclass > policydb.p_classes.nprim) {
- printk(KERN_ERR "security_compute_av: unrecognized class %d\n",
- tclass);
- return -EINVAL;
- }
- tclass_datum = policydb.class_val_to_struct[tclass - 1];
-
/*
* Initialize the access vectors to the default values.
*/
@@ -321,6 +314,9 @@ static int context_struct_compute_av(struct context *scontext,
avd->auditdeny = 0xffffffff;
avd->seqno = latest_granting;
+ if (!tclass || tclass > policydb.p_classes.nprim)
+ return 0;
+
/*
* If a specific type enforcement rule was defined for
* this permission check, then use it.
@@ -358,6 +354,7 @@ static int context_struct_compute_av(struct context *scontext,
* Remove any permissions prohibited by a constraint (this includes
* the MLS policy).
*/
+ tclass_datum = policydb.class_val_to_struct[tclass - 1];
constraint = tclass_datum->constraints;
while (constraint) {
if ((constraint->permissions & (avd->allowed)) &&
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply related [flat|nested] 60+ messages in thread* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-14 16:03 ` Stephen Smalley
@ 2007-06-14 16:13 ` Karl MacMillan
2007-06-14 16:52 ` James Morris
1 sibling, 0 replies; 60+ messages in thread
From: Karl MacMillan @ 2007-06-14 16:13 UTC (permalink / raw)
To: Stephen Smalley
Cc: Chad Sellers, selinux, James Morris, Eric Paris, Serge E. Hallyn
On Thu, 2007-06-14 at 12:03 -0400, Stephen Smalley wrote:
> On Thu, 2007-06-14 at 11:55 -0400, Stephen Smalley wrote:
> > On Thu, 2007-06-14 at 11:40 -0400, Chad Sellers wrote:
> > > On 6/12/07 9:32 AM, "Stephen Smalley" <sds@tycho.nsa.gov> wrote:
> > >
> > > > On Mon, 2007-06-11 at 15:55 -0400, Stephen Smalley wrote:
> > > >> Extend SELinux to allow capabilities to be granted authoritatively.
> > > >> Introduces a new cap_override access vector to indicate when the
> > > >> secondary module (i.e. capability or dummy) check should be skipped.
> > > >> Handle the new class gracefully even if the policy does not yet have
> > > >> it defined.
> > > >
> > > > Ah, I realized that this has the same issue in permissive mode as the
> > > > get_user_sids code - we don't want to arbitrarily allow these
> > > > dac_override permissions in permissive mode (otherwise setenforce 0
> > > > turns off DAC as well), so the following patch should be applied on top:
> > > >
> > > > diff -u b/security/selinux/hooks.c b/security/selinux/hooks.c
> > > > --- b/security/selinux/hooks.c
> > > > +++ b/security/selinux/hooks.c
> > > > @@ -1424,7 +1424,7 @@
> > > > int rc;
> > > >
> > > > rc = avc_has_perm_noaudit(sid, sid, SECCLASS_CAP_OVERRIDE,
> > > > - CAP_TO_MASK(cap), 0, NULL);
> > > > + CAP_TO_MASK(cap), AVC_STRICT, NULL);
> > > > if (rc) {
> > > > rc = secondary_ops->capable(tsk, cap);
> > > > if (rc)
> > > >
> > > > I'll fold that into the base patch for submission.
> > >
> > > This certainly makes the permissive case better than the original patch, but
> > > you're still opening up a new vector for escalation of privilege when
> > > SELinux access controls aren't enforcing. At the very least, policy authors
> > > are going to have to be really careful with this, as it's easy to shoot
> > > yourself in the foot in permissive. One example scenario of escalation:
> > >
> > > A domain is granted cap_override:dac_override in policy. The system is
> > > running in permissive mode. In permissive mode, the only thing that protects
> > > the policy from being reloaded is DAC permissions, which the policy has
> > > granted the domain the ability to override. So, the domain loads a new
> > > policy which grants it cap_override:*. This means that in permissive
> > > dac_override can easily get you all capabilities. Also, note that the same
> > > scenario can be constructed without the original allow rule using a
> > > capability shedding scenario.
> > >
> > > I realize that there are already other scenarios where a program can use
> > > dac_override to escalate to further capabilities. My point is that we seem
> > > to be opening up a new attack vector here.
> >
> > Actually, we don't want the cap_overrides to take affect at all under
> > permissive mode, since permissive mode is generally about avoiding side
> > effects from SELinux permission checks and we lose any inter-domain
> > protection in permissive mode (thus unprivileged domain could take
> > control of domain with cap_overrides). So we would need to restrict the
> > override logic to enforcing mode only.
>
> Like so:
>
This is certainly safer, but it is going to be surprising and make
permissive hard to use for testing. Basically - you would have to make
some executables setuid while developing policy in permissive and remove
setuid when you move to enforcing (unless I'm missing something). Or I
guess you could run the apps under a different uid so that it would
inherit the right capabilities, which introduces a whole other set of
side-effects.
Karl
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-14 16:03 ` Stephen Smalley
2007-06-14 16:13 ` Karl MacMillan
@ 2007-06-14 16:52 ` James Morris
2007-06-14 17:28 ` Chad Sellers
2007-06-14 17:46 ` Stephen Smalley
1 sibling, 2 replies; 60+ messages in thread
From: James Morris @ 2007-06-14 16:52 UTC (permalink / raw)
To: Stephen Smalley; +Cc: Chad Sellers, selinux, Eric Paris, Serge E. Hallyn
On Thu, 14 Jun 2007, Stephen Smalley wrote:
> + if (selinux_enforcing) {
> + rc = avc_has_perm_noaudit(sid, sid, SECCLASS_CAP_OVERRIDE,
> + CAP_TO_MASK(cap), AVC_STRICT, NULL);
> + if (!rc)
> + goto out;
I wonder if this will break applications now -- if their suid bit is
removed, and SELinux authoritatively grants capabilities, they'll just
stop working in permissive mode.
- James
--
James Morris
<jmorris@namei.org>
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-14 16:52 ` James Morris
@ 2007-06-14 17:28 ` Chad Sellers
2007-06-14 17:35 ` James Morris
2007-06-14 17:46 ` Stephen Smalley
1 sibling, 1 reply; 60+ messages in thread
From: Chad Sellers @ 2007-06-14 17:28 UTC (permalink / raw)
To: James Morris, Stephen Smalley; +Cc: selinux, Eric Paris, Serge E. Hallyn
On 6/14/07 12:52 PM, "James Morris" <jmorris@namei.org> wrote:
> On Thu, 14 Jun 2007, Stephen Smalley wrote:
>
>> + if (selinux_enforcing) {
>> + rc = avc_has_perm_noaudit(sid, sid, SECCLASS_CAP_OVERRIDE,
>> + CAP_TO_MASK(cap), AVC_STRICT, NULL);
>> + if (!rc)
>> + goto out;
>
> I wonder if this will break applications now -- if their suid bit is
> removed, and SELinux authoritatively grants capabilities, they'll just
> stop working in permissive mode.
>
Yes, it's definitely an interesting scenario, when a program can succeed in
enforcing but fail in permissive. Though it might help us convince more
people to run in enforcing ;-)
Chad
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-14 17:28 ` Chad Sellers
@ 2007-06-14 17:35 ` James Morris
2007-06-14 17:43 ` Chad Sellers
2007-06-14 17:47 ` Stephen Smalley
0 siblings, 2 replies; 60+ messages in thread
From: James Morris @ 2007-06-14 17:35 UTC (permalink / raw)
To: Chad Sellers; +Cc: Stephen Smalley, selinux, Eric Paris, Serge E. Hallyn
On Thu, 14 Jun 2007, Chad Sellers wrote:
> Yes, it's definitely an interesting scenario, when a program can succeed in
> enforcing but fail in permissive. Though it might help us convince more
> people to run in enforcing ;-)
ITYM "convince more people to disable SELinux"
--
James Morris
<jmorris@namei.org>
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-14 17:35 ` James Morris
@ 2007-06-14 17:43 ` Chad Sellers
2007-06-14 17:47 ` Stephen Smalley
1 sibling, 0 replies; 60+ messages in thread
From: Chad Sellers @ 2007-06-14 17:43 UTC (permalink / raw)
To: James Morris; +Cc: Stephen Smalley, selinux, Eric Paris, Serge E. Hallyn
On 6/14/07 1:35 PM, "James Morris" <jmorris@namei.org> wrote:
> On Thu, 14 Jun 2007, Chad Sellers wrote:
>
>> Yes, it's definitely an interesting scenario, when a program can succeed in
>> enforcing but fail in permissive. Though it might help us convince more
>> people to run in enforcing ;-)
>
> ITYM "convince more people to disable SELinux"
>
No, once Red Hat takes the SUID bit off all their programs and uses SELinux
to grant them capabilities, then neither permissive nor disabled will work.
They'll have to run with SELinux enforcing. ;-)
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-14 17:35 ` James Morris
2007-06-14 17:43 ` Chad Sellers
@ 2007-06-14 17:47 ` Stephen Smalley
2007-06-14 20:02 ` Casey Schaufler
1 sibling, 1 reply; 60+ messages in thread
From: Stephen Smalley @ 2007-06-14 17:47 UTC (permalink / raw)
To: James Morris; +Cc: Chad Sellers, selinux, Eric Paris, Serge E. Hallyn
On Thu, 2007-06-14 at 13:35 -0400, James Morris wrote:
> On Thu, 14 Jun 2007, Chad Sellers wrote:
>
> > Yes, it's definitely an interesting scenario, when a program can succeed in
> > enforcing but fail in permissive. Though it might help us convince more
> > people to run in enforcing ;-)
>
> ITYM "convince more people to disable SELinux"
Actually, the funny thing there is that selinux=0 would have the same
effect if you had stripped the suid bits. Those applications would
_only_ work with selinux enabled and enforcing.
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-14 17:47 ` Stephen Smalley
@ 2007-06-14 20:02 ` Casey Schaufler
0 siblings, 0 replies; 60+ messages in thread
From: Casey Schaufler @ 2007-06-14 20:02 UTC (permalink / raw)
To: Stephen Smalley, James Morris
Cc: Chad Sellers, selinux, Eric Paris, Serge E. Hallyn
--- Stephen Smalley <sds@tycho.nsa.gov> wrote:
> Actually, the funny thing there is that selinux=0 would have the same
> effect if you had stripped the suid bits. Those applications would
> _only_ work with selinux enabled and enforcing.
Stephen's Evil Plan for World Domination revealed! I knew it!
I hope I'm kidding.
Casey Schaufler
casey@schaufler-ca.com
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-14 16:52 ` James Morris
2007-06-14 17:28 ` Chad Sellers
@ 2007-06-14 17:46 ` Stephen Smalley
2007-06-14 18:18 ` James Morris
1 sibling, 1 reply; 60+ messages in thread
From: Stephen Smalley @ 2007-06-14 17:46 UTC (permalink / raw)
To: James Morris; +Cc: Chad Sellers, selinux, Eric Paris, Serge E. Hallyn
On Thu, 2007-06-14 at 12:52 -0400, James Morris wrote:
> On Thu, 14 Jun 2007, Stephen Smalley wrote:
>
> > + if (selinux_enforcing) {
> > + rc = avc_has_perm_noaudit(sid, sid, SECCLASS_CAP_OVERRIDE,
> > + CAP_TO_MASK(cap), AVC_STRICT, NULL);
> > + if (!rc)
> > + goto out;
>
> I wonder if this will break applications now -- if their suid bit is
> removed, and SELinux authoritatively grants capabilities, they'll just
> stop working in permissive mode.
True. A similar issue arises of course in the selinux=0 case, although
there at least we could have some sort of install-time logic to decide
whether to strip suid bits or not based on whether selinux was enabled
w/suitable policy or disabled. But I suppose it is more crucial for
permissive mode due to its use as a temporary state for policy
generation or recovery. Of course, our ultimate goal is to get to the
point where permissive mode is completely unnecessary, i.e. adequate
tools exist that users can always recover or generate policy without
needing to go permissive. Or possibly per-process or per-domain
permissive mode becomes more attractive in light of these kinds of
concerns.
In the short term though, I don't expect distros to make a wholesale
removal of suid bits, whether for this support or for file capabilities
support. It would tend to get used incrementally by newer developments,
and possibly retroactively applied by security-oriented specialized
distros and custom built ones (which tend to disable permissive mode and
selinux=disabled altogether in their kernel configs).
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-14 17:46 ` Stephen Smalley
@ 2007-06-14 18:18 ` James Morris
0 siblings, 0 replies; 60+ messages in thread
From: James Morris @ 2007-06-14 18:18 UTC (permalink / raw)
To: Stephen Smalley; +Cc: Chad Sellers, selinux, Eric Paris, Serge E. Hallyn
On Thu, 14 Jun 2007, Stephen Smalley wrote:
> In the short term though, I don't expect distros to make a wholesale
> removal of suid bits, whether for this support or for file capabilities
> support. It would tend to get used incrementally by newer developments,
> and possibly retroactively applied by security-oriented specialized
> distros and custom built ones (which tend to disable permissive mode and
> selinux=disabled altogether in their kernel configs).
Agreed. Applied selectively, I think it would definitely help people see
the value of SELinux, but should not be enabled by default in a distro at
this stage :-)
--
James Morris
<jmorris@namei.org>
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [RFC][PATCH] selinux: enable authoritative granting of capabilities
2007-06-14 15:40 ` Chad Sellers
2007-06-14 15:55 ` Stephen Smalley
@ 2007-06-14 15:55 ` Karl MacMillan
1 sibling, 0 replies; 60+ messages in thread
From: Karl MacMillan @ 2007-06-14 15:55 UTC (permalink / raw)
To: Chad Sellers
Cc: Stephen Smalley, selinux, James Morris, Eric Paris,
Serge E. Hallyn
On Thu, 2007-06-14 at 11:40 -0400, Chad Sellers wrote:
> On 6/12/07 9:32 AM, "Stephen Smalley" <sds@tycho.nsa.gov> wrote:
>
> > On Mon, 2007-06-11 at 15:55 -0400, Stephen Smalley wrote:
> >> Extend SELinux to allow capabilities to be granted authoritatively.
> >> Introduces a new cap_override access vector to indicate when the
> >> secondary module (i.e. capability or dummy) check should be skipped.
> >> Handle the new class gracefully even if the policy does not yet have
> >> it defined.
> >
> > Ah, I realized that this has the same issue in permissive mode as the
> > get_user_sids code - we don't want to arbitrarily allow these
> > dac_override permissions in permissive mode (otherwise setenforce 0
> > turns off DAC as well), so the following patch should be applied on top:
> >
> > diff -u b/security/selinux/hooks.c b/security/selinux/hooks.c
> > --- b/security/selinux/hooks.c
> > +++ b/security/selinux/hooks.c
> > @@ -1424,7 +1424,7 @@
> > int rc;
> >
> > rc = avc_has_perm_noaudit(sid, sid, SECCLASS_CAP_OVERRIDE,
> > - CAP_TO_MASK(cap), 0, NULL);
> > + CAP_TO_MASK(cap), AVC_STRICT, NULL);
> > if (rc) {
> > rc = secondary_ops->capable(tsk, cap);
> > if (rc)
> >
> > I'll fold that into the base patch for submission.
>
> This certainly makes the permissive case better than the original patch, but
> you're still opening up a new vector for escalation of privilege when
> SELinux access controls aren't enforcing. At the very least, policy authors
> are going to have to be really careful with this, as it's easy to shoot
> yourself in the foot in permissive. One example scenario of escalation:
>
> A domain is granted cap_override:dac_override in policy. The system is
> running in permissive mode. In permissive mode, the only thing that protects
> the policy from being reloaded is DAC permissions, which the policy has
> granted the domain the ability to override. So, the domain loads a new
> policy which grants it cap_override:*. This means that in permissive
> dac_override can easily get you all capabilities. Also, note that the same
> scenario can be constructed without the original allow rule using a
> capability shedding scenario.
>
> I realize that there are already other scenarios where a program can use
> dac_override to escalate to further capabilities. My point is that we seem
> to be opening up a new attack vector here.
>
Or you could just arbitrarily transition to a domain with the
capabilities that you want. I would say that this didn't matter because
permissive shouldn't be used in production, but for some reason people
seem to to do this (I see suggestions on the web for this all the time).
Karl
> Thanks,
> Chad
>
>
> --
> This message was distributed to subscribers of the selinux mailing list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 60+ messages in thread