[RFC v2][PATCH] selinux: enable authoritative granting of capabilities

[RFC v2][PATCH] selinux: enable authoritative granting of capabilities

[Stephen Smalley]

Second RFC on this patch, collects up discussion and changes so far.  If
no objections, then this will be re-posted as just a [PATCH] on selinux
and lkml.

---

Extend SELinux to allow capabilities to be granted authoritatively
based solely on SELinux policy, enabling users of SELinux to
selectively reduce or fully eliminate the need for a "root" user and
setuid executables.  This provides an alternative approach to file
capabilities without conflicting with it.

To date, SELinux has only acted to further restrict the set of
capabilities that a process can use based on policy (the
"restrictive-only" paradigm), enabling SELinux to limit specific
programs (like ping) to using specific capabilities (like net_raw)
based on their domain while still requiring the programs to be setuid
root in order to first obtain the capability and pass the capability
module checking.  That restrictive-only paradigm was taken originally
for SELinux as a conservative strategy to ensure that SELinux did not
weaken the base system protection especially while SELinux was first
being developed and integrated.  However, the long term goal has
always been to enable SELinux to fully manage superuser privileges aka
capabilities based on policy and eliminate the need for setuid
binaries and the "root" user. Similar support was implemented in a
predecessor of SELinux, the DTOS system.  This patch enables SELinux
to achieve this goal.

This support for authoritatively granting capabilities has the
advantages of centralized and analyzable policy (vs. per-file
capability masks or setuid bits distributed throughout the
filesystem), fine-grained and flexible control over privilege changes
(vs. rigid capability evolution logic), and more complete support for
protecting and confining the privileged process through the extensive
controls provided by SELinux.  Naturally, this approach requires
SELinux to be enabled in order to use it, unlike the file capabilities
approach.  This approach also requires SELinux to be in enforcing mode
in order to use it, as it depends on the other SELinux controls to
properly protect the privileged process; as a safety measure, the
capability overrides will not take effect in permissive mode.  Thus, a
program stripped of its setuid bit and granted capabilities via this
mechanism will not gain any privileges if SELinux is put into
permissive mode or disabled, possibly preventing that application from
working.

Using this support safely requires some care in policy writing, as one
must ensure that a domain granted capabilities in this manner cannot
be subverted by a less privileged domain.  Policy interfaces to help
with this task are under development.

No changes to LSM are required for this patch, as LSM already allows
security modules to completely determine the result of the
capability-related computations.  Only the internal interaction
between SELinux and its secondary module (capability or dummy) is
affected through the introduction of a notion of a capability
override.

The patch introduces a new cap_override access vector to indicate when
the capability module should be overridden.  The existing
(restrictive) capability access vector remains unchanged and continues
to be required in order to authorize the capability under the
mandatory policy (forming an upper bound on the capabilities granted
to the domain), regardless of whether the capability is secondarily
granted by the cap_override vector or by the base capability logic.
This separation enables some capabilities to be granted
authoritatively while others can continue to be granted restrictively,
and keeps the meaning of existing policies intact.  Thus, by default
(in the absence of new policy), nothing changes in the system
behavior, and even with new policy that allows cap_override
permissions, anyone can easily audit their policy to see whether and
where they are granting capabilities authoritatively by looking for
rules on the new cap_override class.

Further, since 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 that generate rules from audit messages.  The use of
the _noaudit interface was also motivated by the fact that this check
must necessarily occur before the base capability check (as it can
override it) and would otherwise need to be pervasively dontaudit'd to
avoid noise in the audit logs.

Signed-off-by:  Stephen Smalley <sds@tycho.nsa.gov>

---

 security/selinux/hooks.c                     |   10 +++++++-
 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(+), 8 deletions(-)

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.

[RFC v2][PATCH] refpolicy: add memprotect and cap_override definitions and interfaces

[Stephen Smalley]

Introduce policy definitions and interfaces for the new memprotect and
cap_override classes recently added to the kernel.

Since the prior version of the patch, two changes have been made:

- As observed by Eric Paris, we also need to exclude the file type for
any domain that has cap overrides from being created or relabeled-to by
unconfined_t or unconfined_t can create its own entrypoint program into
such a domain, so add a files_cap_override() interface in addition to
the domain_cap_override() interface.  I would have preferred a single
interface but it doesn't seem to fit with the module encapsulation.

- Added a domain_mmap_low() interface for memprotect:mmap_zero.

Signed-off-by:  Stephen Smalley <sds@tycho.nsa.gov>

---

 policy/flask/access_vectors     |   44 ++++++++++++++++++++++++++++++++++++++++
 policy/flask/security_classes   |    4 +++
 policy/modules/kernel/domain.if |   42 ++++++++++++++++++++++++++++++++++++++
 policy/modules/kernel/domain.te |   15 +++++++++++--
 policy/modules/kernel/files.if  |   18 ++++++++++++++++
 policy/modules/kernel/files.te  |   11 ++++++++--
 6 files changed, 130 insertions(+), 4 deletions(-)

Index: refpolicy/policy/flask/security_classes
===================================================================
--- refpolicy/policy/flask/security_classes	(revision 2333)
+++ 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 2333)
+++ 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/files.if
===================================================================
--- refpolicy/policy/modules/kernel/files.if	(revision 2333)
+++ refpolicy/policy/modules/kernel/files.if	(working copy)
@@ -4588,3 +4588,21 @@
 
 	allow $1 { file_type -security_file_type }:dir manage_dir_perms;
 ')
+
+########################################
+## <summary>
+##	Program type used to enter domain with ability to override capabilities.
+## </summary>
+## <param name="type">
+##	<summary>
+##	Program type.
+##	</summary>
+## </param>
+#
+interface(`files_cap_override',`
+	gen_require(`
+		attribute cap_override_file_type;
+	')
+
+	typeattribute $1 cap_override_file_type;
+')
Index: refpolicy/policy/modules/kernel/domain.if
===================================================================
--- refpolicy/policy/modules/kernel/domain.if	(revision 2333)
+++ refpolicy/policy/modules/kernel/domain.if	(working copy)
@@ -1254,3 +1254,45 @@
 	typeattribute $1 can_change_object_identity;
 	typeattribute $1 set_curr_context;
 ')
+
+########################################
+## <summary>
+##	Ability to mmap a low area of the address space,
+##      as configured by /proc/sys/kernel/mmap_min_addr.
+##      Preventing such mappings helps protect against
+##      exploiting null deref bugs in the kernel.
+## </summary>
+## <param name="domain">
+##	<summary>
+##	Domain allowed to mmap low memory.
+##	</summary>
+## </param>
+#
+interface(`domain_mmap_low',`
+	gen_require(`
+		attribute mmap_low_domain_type;
+	')
+
+	typeattribute $1 mmap_low_domain_type;
+
+	allow $1 self:memprotect mmap_zero;
+')
+
+
+########################################
+## <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/files.te
===================================================================
--- refpolicy/policy/modules/kernel/files.te	(revision 2333)
+++ refpolicy/policy/modules/kernel/files.te	(working copy)
@@ -12,6 +12,9 @@
 attribute mountpoint;
 attribute pidfile;
 
+# For file types that are entrypoints to domains with cap_overrides.
+attribute cap_override_file_type;
+
 # For labeling types that are to be polyinstantiated
 attribute polydir;
 
@@ -212,10 +215,14 @@
 # Unconfined access to this module
 #
 
-# Create/access any file in a labeled filesystem;
-allow files_unconfined_type file_type:{ file chr_file } ~execmod;
+# Create/access any file without cap overrides in a labeled filesystem
+allow files_unconfined_type { file_type - cap_override_file_type }:file ~execmod;
+allow files_unconfined_type file_type:chr_file ~execmod;
 allow files_unconfined_type file_type:{ dir lnk_file sock_file fifo_file blk_file } *;
 
+# Read/execute-only access to files with cap overrides.
+allow files_unconfined_type cap_override_file_type:file { read getattr execute execute_no_trans };
+
 # Mount/unmount any filesystem with the context= option. 
 allow files_unconfined_type file_type:filesystem *;
 
Index: refpolicy/policy/modules/kernel/domain.te
===================================================================
--- refpolicy/policy/modules/kernel/domain.te	(revision 2333)
+++ refpolicy/policy/modules/kernel/domain.te	(working copy)
@@ -15,6 +15,14 @@
 # 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 mmap low memory.
+attribute mmap_low_domain_type;
+neverallow { domain -mmap_low_domain_type } self:memprotect mmap_zero;
+
 # Domains that can set their current context
 # (perform dynamic transitions)
 attribute set_curr_context;
@@ -130,9 +138,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.

Re: [RFC v2][PATCH] refpolicy: add memprotect and cap_override definitions and interfaces

[Christopher J. PeBenito]

On Fri, 2007-06-15 at 10:42 -0400, Stephen Smalley wrote:
> Introduce policy definitions and interfaces for the new memprotect and
> cap_override classes recently added to the kernel.
> 
> Since the prior version of the patch, two changes have been made:
> 
> - As observed by Eric Paris, we also need to exclude the file type for
> any domain that has cap overrides from being created or relabeled-to by
> unconfined_t or unconfined_t can create its own entrypoint program into
> such a domain, so add a files_cap_override() interface in addition to
> the domain_cap_override() interface.  I would have preferred a single
> interface but it doesn't seem to fit with the module encapsulation.
> 
> - Added a domain_mmap_low() interface for memprotect:mmap_zero.

I merged the memprotect portion, but I'm going to hold off on the
cap_override portion until the kernel support starts going upstream.

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

Re: [RFC v2][PATCH] selinux: enable authoritative granting of capabilities

[Casey Schaufler]

--- Stephen Smalley <sds@tycho.nsa.gov> wrote:

> Second RFC on this patch, collects up discussion and changes so far.  If
> no objections, then this will be re-posted as just a [PATCH] on selinux
> and lkml.
> 
> ---
> 
> Extend SELinux to allow capabilities to be granted authoritatively
> based solely on SELinux policy, enabling users of SELinux to
> selectively reduce or fully eliminate the need for a "root" user and
> setuid executables.  This provides an alternative approach to file
> capabilities without conflicting with it.

Why don't you just work with the people who are getting the
file capabilities working and integrate that into SELinux?
Why do you have to take this tangent and confuse everything?

There. An objection. I do not believe you've demonstrated that
using the proposed file capabilities can't get you what you
want, and that we don't need two implementations of the same
thing.


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.

Re: [RFC v2][PATCH] selinux: enable authoritative granting of capabilities

[Stephen Smalley]

On Fri, 2007-06-15 at 08:14 -0700, Casey Schaufler wrote:
> --- Stephen Smalley <sds@tycho.nsa.gov> wrote:
> 
> > Second RFC on this patch, collects up discussion and changes so far.  If
> > no objections, then this will be re-posted as just a [PATCH] on selinux
> > and lkml.
> > 
> > ---
> > 
> > Extend SELinux to allow capabilities to be granted authoritatively
> > based solely on SELinux policy, enabling users of SELinux to
> > selectively reduce or fully eliminate the need for a "root" user and
> > setuid executables.  This provides an alternative approach to file
> > capabilities without conflicting with it.
> 
> Why don't you just work with the people who are getting the
> file capabilities working and integrate that into SELinux?
> Why do you have to take this tangent and confuse everything?
> 
> There. An objection. I do not believe you've demonstrated that
> using the proposed file capabilities can't get you what you
> want, and that we don't need two implementations of the same
> thing.

I don't think you've taken the time to read and understand the
description or the code, or you might realize that your characterization
above is false.

I did provide feedback to Serge on the file capabilities support as it
was being developed.  It will work with SELinux, with or without this
change.  But it doesn't solve the same problem.  Read it again.  Please.
And Serge, who authored the file capability support, understands that,
and appears to like our patch from his comments on list.  So there is no
conflict between us and the "file capabilities" people, only between us
and people who don't bother to take the time to understand what they are
commenting on...

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

Re: [RFC v2][PATCH] selinux: enable authoritative granting of capabilities

[Casey Schaufler]

--- Stephen Smalley <sds@tycho.nsa.gov> wrote:

> On Fri, 2007-06-15 at 08:14 -0700, Casey Schaufler wrote:
> > --- Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > 
> > > Second RFC on this patch, collects up discussion and changes so far.  If
> > > no objections, then this will be re-posted as just a [PATCH] on selinux
> > > and lkml.
> > > 
> > > ---
> > > 
> > > Extend SELinux to allow capabilities to be granted authoritatively
> > > based solely on SELinux policy, enabling users of SELinux to
> > > selectively reduce or fully eliminate the need for a "root" user and
> > > setuid executables.  This provides an alternative approach to file
> > > capabilities without conflicting with it.
> > 
> > Why don't you just work with the people who are getting the
> > file capabilities working and integrate that into SELinux?
> > Why do you have to take this tangent and confuse everything?
> > 
> > There. An objection. I do not believe you've demonstrated that
> > using the proposed file capabilities can't get you what you
> > want, and that we don't need two implementations of the same
> > thing.
> 
> I don't think you've taken the time to read and understand the
> description or the code, or you might realize that your characterization
> above is false.

I have read and understand the description and have examined the
code, although I confess that it is the intent that I object to,
not the implementation of that intent. It's a fine implementation
of the description.

> I did provide feedback to Serge on the file capabilities support as it
> was being developed.  It will work with SELinux, with or without this
> change.  But it doesn't solve the same problem.  Read it again.  Please.
> And Serge, who authored the file capability support, understands that,
> and appears to like our patch from his comments on list.  So there is no
> conflict between us and the "file capabilities" people, only between us
> and people who don't bother to take the time to understand what they are
> commenting on...

Yeah, and the horse you rode in on.

Look, you're always badgering people to explain why their LSM
facilities can't be done using SELinux, or a tweek to SELinux.
When you take this to LKML expect to get exactly the same question
(as I posed here) about why SELinux "can't just use" the file
capabilities. In all your whinging about me above you never answered
the question. I understand your design goals, and given your
design goals I completely understand why you would want to do it
the way you've outlined.

My concern is with the future of file capabilities, which I like.
I would like to see them move forward for my own nefarious purposes.
Those purposes do not require the sophistication of SELinux, so
I do not want to see the advance of file capabilities run up
against the "SELinux does that, ''just'' use SELinux" argument
every time someone wants to improve it. It gets tiresome and
consumes way to much of the limited time I have to work on projects.

So please explain, so that even an MLS junkie like me can understand,
why you can't "just" use the file capability machanism as it's
designed. I read what you wrote. I read the code. Humor me and
answer the question if you'd be so kind. I'm sure that you have
a good reason and sufficient understanding of all the surrounding
issues to make it clear.

Thank you.



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.

Re: [RFC v2][PATCH] selinux: enable authoritative granting of capabilities

[Karl MacMillan]

On Fri, 2007-06-15 at 09:05 -0700, Casey Schaufler wrote:
> --- Stephen Smalley <sds@tycho.nsa.gov> wrote:
> 

[...]

> 
> So please explain, so that even an MLS junkie like me can understand,
> why you can't "just" use the file capability machanism as it's
> designed. I read what you wrote. I read the code. Humor me and
> answer the question if you'd be so kind. I'm sure that you have
> a good reason and sufficient understanding of all the surrounding
> issues to make it clear.
> 

It's not clear to me what you mean by "using" the file capability
mechanism. In the current implementation, if file caps are used SELinux
can either a) use those caps with optional additional restrictions (just
like current inherited capabilities) or b) override those capabilities.
The policy writer then can choose whether to "use" the file capabilities
or use the native selinux policy mechanism.

As for why it is important to add the selinux cap_override mechanism,
this has been explained many times in this thread (hence the
exasperation with your constant questioning and implying of conflict
where there is none). The file capability mechanism puts policy in the
xattr. A primary goal of SELinux is to have a central, analyzable
policy. These things cannot be reconciled.

Does this answer your question?

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.

Re: [RFC v2][PATCH] selinux: enable authoritative granting of capabilities

[Stephen Smalley]

On Fri, 2007-06-15 at 09:05 -0700, Casey Schaufler wrote:
> Look, you're always badgering people to explain why their LSM
> facilities can't be done using SELinux, or a tweek to SELinux.
> When you take this to LKML expect to get exactly the same question
> (as I posed here) about why SELinux "can't just use" the file
> capabilities.

File capabilities don't allow us to assign domain Foo (corresponding to
a program, a set of programs, a user role, whatever) a capability solely
through SELinux policy; we have to separately and independently set a
file capability bitmask on the file in addition to allowing the
capability under the SELinux policy, and we are limited to the fixed
capability evolution rules - we can't adjust them to fit specific needs
as domains transition as we can in policy.  That's the difference; file
capabilities remain an orthogonal mechanism outside of our policy that
has to be separately managed, assigned to files, preserved across
prelinks and updates, incorporated into analysis, etc.

> My concern is with the future of file capabilities, which I like.
> I would like to see them move forward for my own nefarious purposes.
> Those purposes do not require the sophistication of SELinux, so
> I do not want to see the advance of file capabilities run up
> against the "SELinux does that, ''just'' use SELinux" argument
> every time someone wants to improve it. It gets tiresome and
> consumes way to much of the limited time I have to work on projects.

This provides a mechanism for people who use SELinux already to manage
their capabilities fully via SELinux based on roles and domains.  File
capabilities provides a mechanism for people who don't use SELinux to
manage their capabilities based on per-file EAs.  They can both be
merged into mainline as far as I'm concerned.

> So please explain, so that even an MLS junkie like me can understand,
> why you can't "just" use the file capability machanism as it's
> designed.

It is about being able to fully manage capabilities in policy, just as
we already fully manage MLS overrides in policy.

Look, with current SELinux, we have policy rules like:
	allow ping_t self:capability net_raw;
	allow ping_t ping_exec_t:file entrypoint;
	...
and rpm and friends apply the file contexts mapping to assign
ping_exec_t to /bin/ping for us when ping is installed/updated and
prelink knows to preserve that context when prelink'ing the binary, etc.
And although /bin/ping is suid root, it can only ever use the
capabilities we've allowed it in policy.

With my patch, we can further take away the suid root'ness of /bin/ping
and add a single allow ping_t self:cap_override net_raw; to policy and
we're done - ping is now able to run with net_raw and policy is
centralized.  In fact, we wouldn't even need that separate allow rule if
we just made the existing SELinux capability allow rules always
authoritative, but I'm taking the conservative and compatible route - no
change to existing behavior.

With file capabilities, we have to add an entirely new extended
attribute (security.capability) to /bin/ping, where that attribute
directly encodes policy (the actual capability bits, not just a
descriptive type tag), and now we have duplicated state between policy
and filesystem.  From a management point of view, the situation is now
worse than the setuid root binary - I have redundant capability bitmaps
that I am managing in policy and on a per-file basis.  Meanwhile, rpm
and friends, prelink, etc have no knowledge of this security.capability
and will cheerfully blow it away until they are all updated.

File capabilities are helpful for non-selinux systems.  They don't help
users of SELinux much at all, if any.

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

Re: [RFC v2][PATCH] selinux: enable authoritative granting of capabilities

[Casey Schaufler]

--- Stephen Smalley <sds@tycho.nsa.gov> wrote:

> On Fri, 2007-06-15 at 09:05 -0700, Casey Schaufler wrote:
> > Look, you're always badgering people to explain why their LSM
> > facilities can't be done using SELinux, or a tweek to SELinux.
> > When you take this to LKML expect to get exactly the same question
> > (as I posed here) about why SELinux "can't just use" the file
> > capabilities.
> 
> File capabilities don't allow us to assign domain Foo (corresponding to
> a program, a set of programs, a user role, whatever) a capability solely
> through SELinux policy; we have to separately and independently set a
> file capability bitmask on the file in addition to allowing the
> capability under the SELinux policy, and we are limited to the fixed
> capability evolution rules - we can't adjust them to fit specific needs
> as domains transition as we can in policy.  That's the difference; file
> capabilities remain an orthogonal mechanism outside of our policy that
> has to be separately managed, assigned to files, preserved across
> prelinks and updates, incorporated into analysis, etc.
> 
> > My concern is with the future of file capabilities, which I like.
> > I would like to see them move forward for my own nefarious purposes.
> > Those purposes do not require the sophistication of SELinux, so
> > I do not want to see the advance of file capabilities run up
> > against the "SELinux does that, ''just'' use SELinux" argument
> > every time someone wants to improve it. It gets tiresome and
> > consumes way to much of the limited time I have to work on projects.
> 
> This provides a mechanism for people who use SELinux already to manage
> their capabilities fully via SELinux based on roles and domains.  File
> capabilities provides a mechanism for people who don't use SELinux to
> manage their capabilities based on per-file EAs.  They can both be
> merged into mainline as far as I'm concerned.
> 
> > So please explain, so that even an MLS junkie like me can understand,
> > why you can't "just" use the file capability machanism as it's
> > designed.
> 
> It is about being able to fully manage capabilities in policy, just as
> we already fully manage MLS overrides in policy.
> 
> Look, with current SELinux, we have policy rules like:
> 	allow ping_t self:capability net_raw;
> 	allow ping_t ping_exec_t:file entrypoint;
> 	...
> and rpm and friends apply the file contexts mapping to assign
> ping_exec_t to /bin/ping for us when ping is installed/updated and
> prelink knows to preserve that context when prelink'ing the binary, etc.
> And although /bin/ping is suid root, it can only ever use the
> capabilities we've allowed it in policy.
> 
> With my patch, we can further take away the suid root'ness of /bin/ping
> and add a single allow ping_t self:cap_override net_raw; to policy and
> we're done - ping is now able to run with net_raw and policy is
> centralized.  In fact, we wouldn't even need that separate allow rule if
> we just made the existing SELinux capability allow rules always
> authoritative, but I'm taking the conservative and compatible route - no
> change to existing behavior.
> 
> With file capabilities, we have to add an entirely new extended
> attribute (security.capability) to /bin/ping, where that attribute
> directly encodes policy (the actual capability bits, not just a
> descriptive type tag), and now we have duplicated state between policy
> and filesystem.  From a management point of view, the situation is now
> worse than the setuid root binary - I have redundant capability bitmaps
> that I am managing in policy and on a per-file basis.  Meanwhile, rpm
> and friends, prelink, etc have no knowledge of this security.capability
> and will cheerfully blow it away until they are all updated.
> 
> File capabilities are helpful for non-selinux systems.  They don't help
> users of SELinux much at all, if any.

Thank you.

Are you planning to do the same with mode bits? Your arguments
would apply equally well for them, too. It's the authoritative
hooks arguement.




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.

Re: [RFC v2][PATCH] selinux: enable authoritative granting of capabilities

[Stephen Smalley]

On Fri, 2007-06-15 at 13:50 -0700, Casey Schaufler wrote:
> --- Stephen Smalley <sds@tycho.nsa.gov> wrote:
> 
> > On Fri, 2007-06-15 at 09:05 -0700, Casey Schaufler wrote:
> > > Look, you're always badgering people to explain why their LSM
> > > facilities can't be done using SELinux, or a tweek to SELinux.
> > > When you take this to LKML expect to get exactly the same question
> > > (as I posed here) about why SELinux "can't just use" the file
> > > capabilities.
> > 
> > File capabilities don't allow us to assign domain Foo (corresponding to
> > a program, a set of programs, a user role, whatever) a capability solely
> > through SELinux policy; we have to separately and independently set a
> > file capability bitmask on the file in addition to allowing the
> > capability under the SELinux policy, and we are limited to the fixed
> > capability evolution rules - we can't adjust them to fit specific needs
> > as domains transition as we can in policy.  That's the difference; file
> > capabilities remain an orthogonal mechanism outside of our policy that
> > has to be separately managed, assigned to files, preserved across
> > prelinks and updates, incorporated into analysis, etc.
> > 
> > > My concern is with the future of file capabilities, which I like.
> > > I would like to see them move forward for my own nefarious purposes.
> > > Those purposes do not require the sophistication of SELinux, so
> > > I do not want to see the advance of file capabilities run up
> > > against the "SELinux does that, ''just'' use SELinux" argument
> > > every time someone wants to improve it. It gets tiresome and
> > > consumes way to much of the limited time I have to work on projects.
> > 
> > This provides a mechanism for people who use SELinux already to manage
> > their capabilities fully via SELinux based on roles and domains.  File
> > capabilities provides a mechanism for people who don't use SELinux to
> > manage their capabilities based on per-file EAs.  They can both be
> > merged into mainline as far as I'm concerned.
> > 
> > > So please explain, so that even an MLS junkie like me can understand,
> > > why you can't "just" use the file capability machanism as it's
> > > designed.
> > 
> > It is about being able to fully manage capabilities in policy, just as
> > we already fully manage MLS overrides in policy.
> > 
> > Look, with current SELinux, we have policy rules like:
> > 	allow ping_t self:capability net_raw;
> > 	allow ping_t ping_exec_t:file entrypoint;
> > 	...
> > and rpm and friends apply the file contexts mapping to assign
> > ping_exec_t to /bin/ping for us when ping is installed/updated and
> > prelink knows to preserve that context when prelink'ing the binary, etc.
> > And although /bin/ping is suid root, it can only ever use the
> > capabilities we've allowed it in policy.
> > 
> > With my patch, we can further take away the suid root'ness of /bin/ping
> > and add a single allow ping_t self:cap_override net_raw; to policy and
> > we're done - ping is now able to run with net_raw and policy is
> > centralized.  In fact, we wouldn't even need that separate allow rule if
> > we just made the existing SELinux capability allow rules always
> > authoritative, but I'm taking the conservative and compatible route - no
> > change to existing behavior.
> > 
> > With file capabilities, we have to add an entirely new extended
> > attribute (security.capability) to /bin/ping, where that attribute
> > directly encodes policy (the actual capability bits, not just a
> > descriptive type tag), and now we have duplicated state between policy
> > and filesystem.  From a management point of view, the situation is now
> > worse than the setuid root binary - I have redundant capability bitmaps
> > that I am managing in policy and on a per-file basis.  Meanwhile, rpm
> > and friends, prelink, etc have no knowledge of this security.capability
> > and will cheerfully blow it away until they are all updated.
> > 
> > File capabilities are helpful for non-selinux systems.  They don't help
> > users of SELinux much at all, if any.
> 
> Thank you.
> 
> Are you planning to do the same with mode bits? Your arguments
> would apply equally well for them, too. It's the authoritative
> hooks arguement.

The mandatory security policy doesn't depend on the mode bits / DAC, and
thus remains orthogonal to it.  The mandatory security policy does
depend on controlling the use of capabilities (e.g. a process with
CAP_SYS_RAWIO can easily subvert the intent of the mandatory policy, and
a number of capability checks have no separate check/LSM hook so we need
the mandatory capability check for complete coverage), and already
controls their use (restrictively).  Extending SELinux to further grant
capabilities authoritatively isn't much of a stretch.  Doing the same
for mode bits would extend SELinux beyond what it needs for mandatory
protection and run into compatibility issues with the pervasive use of
mode bits by users and applications.  I don't think the analogy fits.

Let me ask you what your counter-proposal is.  The situation today is
that one must authorize a program for capabilities twice:
- in the filesystem state via setuid or file capabilities, and
- in SELinux policy.

Do you view that status quo as acceptable or desirable long term?
  
-- 
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.

Re: [RFC v2][PATCH] selinux: enable authoritative granting of capabilities

[Casey Schaufler]

--- Stephen Smalley <sds@tycho.nsa.gov> wrote:


> The mandatory security policy

Let's get our words strait. I believe that what you're talking
about here is the SELinux mechanism for enforcing the policy
provided from user space.

> doesn't depend on the mode bits / DAC, and
> thus remains orthogonal to it.

You could certainly incorporate the mode bits and/or ACLs
into the userland tools that generate policy. Why, for the
time being you could even us restoreconfigd to keep the labels
in sync with changing mode bits. I'm not saying that I want
you to do this. In truth, I don't much care, but I can certainly
see someone making a case for doing it, and once that gets
through it's only a matter of time before it starts looking
as if putting it in the kernel wouldn't be a bad idea.

> The mandatory security policy does
> depend on controlling the use of capabilities (e.g. a process with
> CAP_SYS_RAWIO can easily subvert the intent of the mandatory policy, and
> a number of capability checks have no separate check/LSM hook so we need
> the mandatory capability check for complete coverage), and already
> controls their use (restrictively).  Extending SELinux to further grant
> capabilities authoritatively isn't much of a stretch.  Doing the same
> for mode bits would extend SELinux beyond what it needs for mandatory
> protection and run into compatibility issues with the pervasive use of
> mode bits by users and applications.  I don't think the analogy fits.
> 
> Let me ask you what your counter-proposal is.  The situation today is
> that one must authorize a program for capabilities twice:
> - in the filesystem state via setuid or file capabilities, and
> - in SELinux policy.
> 
> Do you view that status quo as acceptable or desirable long term?

This is exactly how traditional Unix MLS systems with capabilities
behave. To perform a chmod on a file you don't own on Irix you need
CAP_FOWNER. To preform the same action on Trusted Irix you may also
need CAP_MAC_READ, CAP_MAC_WRITE, or both. My counter proposal?

"Just" add the POSIX CAP_MAC_... capabilities to capability.h and
have SELinux use them, using the existing capabilities mechanisms
like everyone else. You've just made a pass through the SELinux
code to switch to authoritative capability handling, so you should
know all the places the you'd need to consider changing. Let me know
if you need help figuring out how to cleanly apply capabilities to
a mandatory access control facility. 

I wouldn't be too surprised if someone proposed those
capabilities be introduced in the near future anyway.


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.

Re: [RFC v2][PATCH] selinux: enable authoritative granting of capabilities

[Stephen Smalley]

On Mon, 2007-06-18 at 08:32 -0700, Casey Schaufler wrote:
> --- Stephen Smalley <sds@tycho.nsa.gov> wrote:
> 
> 
> > The mandatory security policy
> 
> Let's get our words strait. I believe that what you're talking
> about here is the SELinux mechanism for enforcing the policy
> provided from user space.
> 
> > doesn't depend on the mode bits / DAC, and
> > thus remains orthogonal to it.
> 
> You could certainly incorporate the mode bits and/or ACLs
> into the userland tools that generate policy. Why, for the
> time being you could even us restoreconfigd to keep the labels
> in sync with changing mode bits. I'm not saying that I want
> you to do this. In truth, I don't much care, but I can certainly
> see someone making a case for doing it, and once that gets
> through it's only a matter of time before it starts looking
> as if putting it in the kernel wouldn't be a bad idea.
> 
> > The mandatory security policy does
> > depend on controlling the use of capabilities (e.g. a process with
> > CAP_SYS_RAWIO can easily subvert the intent of the mandatory policy, and
> > a number of capability checks have no separate check/LSM hook so we need
> > the mandatory capability check for complete coverage), and already
> > controls their use (restrictively).  Extending SELinux to further grant
> > capabilities authoritatively isn't much of a stretch.  Doing the same
> > for mode bits would extend SELinux beyond what it needs for mandatory
> > protection and run into compatibility issues with the pervasive use of
> > mode bits by users and applications.  I don't think the analogy fits.
> > 
> > Let me ask you what your counter-proposal is.  The situation today is
> > that one must authorize a program for capabilities twice:
> > - in the filesystem state via setuid or file capabilities, and
> > - in SELinux policy.
> > 
> > Do you view that status quo as acceptable or desirable long term?
> 
> This is exactly how traditional Unix MLS systems with capabilities
> behave. To perform a chmod on a file you don't own on Irix you need
> CAP_FOWNER. To preform the same action on Trusted Irix you may also
> need CAP_MAC_READ, CAP_MAC_WRITE, or both. My counter proposal?
> 
> "Just" add the POSIX CAP_MAC_... capabilities to capability.h and
> have SELinux use them, using the existing capabilities mechanisms
> like everyone else. You've just made a pass through the SELinux
> code to switch to authoritative capability handling, so you should
> know all the places the you'd need to consider changing. Let me know
> if you need help figuring out how to cleanly apply capabilities to
> a mandatory access control facility. 
> 
> I wouldn't be too surprised if someone proposed those
> capabilities be introduced in the near future anyway.

First, such capabilities would be redundant.  We can already express MLS
overrides via policy today, without needing capabilities to be defined
for them at all.

Second, one of the motivations for Type Enforcement was to allow
exceptions/overrides to be expressed directly in the policy itself,
rather than requiring a separate orthogonal mechanism like
capabilities/privileges.  Along with using that same policy to protect
those privileged subjects from untrustworthy inputs, to bind them to
specific code, and to limit them to least privilege to contain the
damage that can come from them.

What you are proposing is in direct opposition to our goals and design.
You can certainly disagree with those goals and design, but it makes
arguing about how we are approaching the problem rather pointless.

So let's just agree to disagree.   Get file capabilities into mainline
and fully integrated so that people can use that mechanism for assigning
capabilities, and extend SELinux with this patch so that people can use
SELinux for assigning capabilities, and let the users decide.

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

Re: [RFC v2][PATCH] selinux: enable authoritative granting of capabilities

[Casey Schaufler]

--- Stephen Smalley <sds@tycho.nsa.gov> wrote:

> On Mon, 2007-06-18 at 08:32 -0700, Casey Schaufler wrote:
> > --- Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > 
> > 
> > > The mandatory security policy
> > 
> > Let's get our words strait. I believe that what you're talking
> > about here is the SELinux mechanism for enforcing the policy
> > provided from user space.
> > 
> > > doesn't depend on the mode bits / DAC, and
> > > thus remains orthogonal to it.
> > 
> > You could certainly incorporate the mode bits and/or ACLs
> > into the userland tools that generate policy. Why, for the
> > time being you could even us restoreconfigd to keep the labels
> > in sync with changing mode bits. I'm not saying that I want
> > you to do this. In truth, I don't much care, but I can certainly
> > see someone making a case for doing it, and once that gets
> > through it's only a matter of time before it starts looking
> > as if putting it in the kernel wouldn't be a bad idea.
> > 
> > > The mandatory security policy does
> > > depend on controlling the use of capabilities (e.g. a process with
> > > CAP_SYS_RAWIO can easily subvert the intent of the mandatory policy, and
> > > a number of capability checks have no separate check/LSM hook so we need
> > > the mandatory capability check for complete coverage), and already
> > > controls their use (restrictively).  Extending SELinux to further grant
> > > capabilities authoritatively isn't much of a stretch.  Doing the same
> > > for mode bits would extend SELinux beyond what it needs for mandatory
> > > protection and run into compatibility issues with the pervasive use of
> > > mode bits by users and applications.  I don't think the analogy fits.
> > > 
> > > Let me ask you what your counter-proposal is.  The situation today is
> > > that one must authorize a program for capabilities twice:
> > > - in the filesystem state via setuid or file capabilities, and
> > > - in SELinux policy.
> > > 
> > > Do you view that status quo as acceptable or desirable long term?
> > 
> > This is exactly how traditional Unix MLS systems with capabilities
> > behave. To perform a chmod on a file you don't own on Irix you need
> > CAP_FOWNER. To preform the same action on Trusted Irix you may also
> > need CAP_MAC_READ, CAP_MAC_WRITE, or both. My counter proposal?
> > 
> > "Just" add the POSIX CAP_MAC_... capabilities to capability.h and
> > have SELinux use them, using the existing capabilities mechanisms
> > like everyone else. You've just made a pass through the SELinux
> > code to switch to authoritative capability handling, so you should
> > know all the places the you'd need to consider changing. Let me know
> > if you need help figuring out how to cleanly apply capabilities to
> > a mandatory access control facility. 
> > 
> > I wouldn't be too surprised if someone proposed those
> > capabilities be introduced in the near future anyway.
> 
> First, such capabilities would be redundant.  We can already express MLS
> overrides via policy today, without needing capabilities to be defined
> for them at all.

Nosir, that is not what CAP_MAC_READ should do in the SELinux case.
That capability would override the SELinux policy in completely,
not just the MLS component. On Trusted Irix CAP_MAC_READ overrides
both the sensitivity policy (Bell & LaPadula) and the integrity
policy (Biba). That is why it is CAP_MAC_READ not CAP_MLS_READ,
to allow for cases where policies beyond MLS are desired.

I expect that the counter to this is that SELinux policy can be
configured so as to allow SELinux policy to be overridden. I can
accept that.

> Second, one of the motivations for Type Enforcement was to allow
> exceptions/overrides to be expressed directly in the policy itself,
> rather than requiring a separate orthogonal mechanism like
> capabilities/privileges.

There is an argument to be made for the grand unified access control
scheme. The POSIX group felt (back in the stone age, I'll admit) that
the flexibiliy of distinct mechanisms would be more conducive to
their adoption. In fact, one of the biggest reasons cited for the
eventual withdrawl of the 1e/2c draft was that you had to approve of
the whole thing. Some of the individual sections, it was generally
agreed, could have been approved without the baggage of some of the
others. 

> Along with using that same policy to protect
> those privileged subjects from untrustworthy inputs, to bind them to
> specific code, and to limit them to least privilege to contain the
> damage that can come from them.
> 
> What you are proposing is in direct opposition to our goals and design.
> You can certainly disagree with those goals and design, but it makes
> arguing about how we are approaching the problem rather pointless.

Well, there it is.

> So let's just agree to disagree.   Get file capabilities into mainline
> and fully integrated so that people can use that mechanism for assigning
> capabilities, and extend SELinux with this patch so that people can use
> SELinux for assigning capabilities, and let the users decide.

So long as we're all accepting of that, sure.


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.

Re: [RFC v2][PATCH] selinux: enable authoritative granting of capabilities

[Stephen Smalley]

An alternative approach to implementing this support for authoritative
granting of capabilities by SELinux would be to compute the full
cap_override access vector upon exec and cap_combine it with the base
capability sets, such that the task's capability bitmasks would reflect
the combined capabilities authorized by the base logic and by SELinux
policy.  Then the capable() hook itself would remain unchanged from the
current (unpatched) code, just checking the task's capability bitmask
and then checking the SELinux capability access vector as a further
restriction on use.

There are two places where that computation and combination could be
done: before the usual capability evolution logic is applied (by
cap_bprm_apply_creds) or after it.  If before, we'd be manipulating the
bprm capability bitmasks (similar to file capabilities) and then letting
the usual capability evolution occur; if after, we'd be manipulating the
task capability bitmasks after they have been updated by the capability
module.

Observations:
- This approach would make the granting of such capabilities visible in
the task's capability bitmasks as returned by capget
or /proc/self/status.  Those bitmasks would however still not reflect
the further restrictions imposed by the SELinux capability access vector
check.
- This approach would enable the existing capability-based tests to
provide some protection of the privileged process even apart from the
SELinux checks, although such protection will still be incomplete
without the SELinux checks (e.g. we'd gain separate ptrace checking
based on capabilities, but still depend on selinux control over
creating/relabeling-to the entrypoint type for the domain).  The extent
of additional checking depends on whether we do the manipulation before
or after the usual evolution logic as well; if before, we pick up the
usual checking on exec; if after, we don't.
- Doing the computation and combination first and then applying the
usual evolution logic has a cost in flexibility as it won't support
orthogonal changes in capabilities.

Thoughts?

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

Re: [RFC v2][PATCH] selinux: enable authoritative granting of capabilities

[Serge E. Hallyn]

Quoting Stephen Smalley (sds@tycho.nsa.gov):
> An alternative approach to implementing this support for authoritative
> granting of capabilities by SELinux would be to compute the full
> cap_override access vector upon exec and cap_combine it with the base
> capability sets, such that the task's capability bitmasks would reflect
> the combined capabilities authorized by the base logic and by SELinux
> policy.  Then the capable() hook itself would remain unchanged from the
> current (unpatched) code, just checking the task's capability bitmask
> and then checking the SELinux capability access vector as a further
> restriction on use.
> 
> There are two places where that computation and combination could be
> done: before the usual capability evolution logic is applied (by
> cap_bprm_apply_creds) or after it.  If before, we'd be manipulating the
> bprm capability bitmasks (similar to file capabilities) and then letting
> the usual capability evolution occur; if after, we'd be manipulating the
> task capability bitmasks after they have been updated by the capability
> module.
> 
> Observations:
> - This approach would make the granting of such capabilities visible in
> the task's capability bitmasks as returned by capget
> or /proc/self/status.

That's kind of cool, but I guess it would also lead to policy
reloads not fully affecting the capabilities granted to already
running programs.  So if you remove CAP_NET_RAW from ping_t,
some long-running ping (haha, insert your own better example here)
would continue to run with CAP_NET_RAW, right?

Was there ever any mention of just stopping the stacking with
capability, and just letting selinux handle all it's own capability
logic?  Oh, yes, (vaguely recalling) the argument was about turning
selinux off?  But with the authoritative capabilities logic being
added to selinux that would be a problem anyway, right?

> Those bitmasks would however still not reflect
> the further restrictions imposed by the SELinux capability access vector
> check.
> - This approach would enable the existing capability-based tests to
> provide some protection of the privileged process even apart from the
> SELinux checks, although such protection will still be incomplete
> without the SELinux checks (e.g. we'd gain separate ptrace checking
> based on capabilities, but still depend on selinux control over
> creating/relabeling-to the entrypoint type for the domain).  The extent
> of additional checking depends on whether we do the manipulation before
> or after the usual evolution logic as well; if before, we pick up the
> usual checking on exec; if after, we don't.
> - Doing the computation and combination first and then applying the
> usual evolution logic has a cost in flexibility as it won't support
> orthogonal changes in capabilities.

What do you mean by orthogonal changes in capabilities?  Do you mean
selinux interpreting some caps differently from the capability module?

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

Re: [RFC v2][PATCH] selinux: enable authoritative granting of capabilities

[Stephen Smalley]

On Wed, 2007-06-20 at 15:13 -0500, Serge E. Hallyn wrote:
> Quoting Stephen Smalley (sds@tycho.nsa.gov):
> > An alternative approach to implementing this support for authoritative
> > granting of capabilities by SELinux would be to compute the full
> > cap_override access vector upon exec and cap_combine it with the base
> > capability sets, such that the task's capability bitmasks would reflect
> > the combined capabilities authorized by the base logic and by SELinux
> > policy.  Then the capable() hook itself would remain unchanged from the
> > current (unpatched) code, just checking the task's capability bitmask
> > and then checking the SELinux capability access vector as a further
> > restriction on use.
> > 
> > There are two places where that computation and combination could be
> > done: before the usual capability evolution logic is applied (by
> > cap_bprm_apply_creds) or after it.  If before, we'd be manipulating the
> > bprm capability bitmasks (similar to file capabilities) and then letting
> > the usual capability evolution occur; if after, we'd be manipulating the
> > task capability bitmasks after they have been updated by the capability
> > module.
> > 
> > Observations:
> > - This approach would make the granting of such capabilities visible in
> > the task's capability bitmasks as returned by capget
> > or /proc/self/status.
> 
> That's kind of cool, but I guess it would also lead to policy
> reloads not fully affecting the capabilities granted to already
> running programs.  So if you remove CAP_NET_RAW from ping_t,
> some long-running ping (haha, insert your own better example here)
> would continue to run with CAP_NET_RAW, right?

Suppose that you granted ping_t net_raw authoritatively via the
following pair of rules (both required):
# Allow ping_t to use net_raw capability; checked-on-use.
allow ping_t self:capability net_raw;
# Grant ping_t net_raw capability even if not suid; checked-on-exec.
allow ping_t self:cap_override net_raw;

Now you want to revoke net_raw from ping_t (or possibly both allow rules
were under a boolean in the first place, and you are toggling the
boolean).  You can still remove/disable the first rule and thus revoke
any further use of the capability.

> Was there ever any mention of just stopping the stacking with
> capability, and just letting selinux handle all it's own capability
> logic?  Oh, yes, (vaguely recalling) the argument was about turning
> selinux off?  But with the authoritative capabilities logic being
> added to selinux that would be a problem anyway, right?

That approach has several disadvantages:
- it changes the semantic meaning of existing policies:  allow a_t
self:capability { a b c }; changes from being an upper bound on what
capabilities a_t can ever exercise to being a direct grant of those
capabilities to all a_t processes.  Note for example that SELinux policy
allows all capabilities to unconfined_t, yet ordinary user processes in
unconfined_t can only exercise capabilities via setuid root programs
under the current scheme, and we wouldn't want that to change wholesale.
- it removes a protection boundary on which existing policies were
relying:  the need to change uids or at least capability bitmasks
provided an orthogonal protection check between processes, so it was ok
for e.g. processes with differing capability sets to run in the same
domain formerly (again as in unconfined_t).
- it applies the behavior change globally rather than selectively on a
per-domain per-capability basis (vs. having separate allow a_t
self:cap_override rules that can specify any subset of the ones allowed
by the capability rule).

> 
> > Those bitmasks would however still not reflect
> > the further restrictions imposed by the SELinux capability access vector
> > check.
> > - This approach would enable the existing capability-based tests to
> > provide some protection of the privileged process even apart from the
> > SELinux checks, although such protection will still be incomplete
> > without the SELinux checks (e.g. we'd gain separate ptrace checking
> > based on capabilities, but still depend on selinux control over
> > creating/relabeling-to the entrypoint type for the domain).  The extent
> > of additional checking depends on whether we do the manipulation before
> > or after the usual evolution logic as well; if before, we pick up the
> > usual checking on exec; if after, we don't.
> > - Doing the computation and combination first and then applying the
> > usual evolution logic has a cost in flexibility as it won't support
> > orthogonal changes in capabilities.
> 
> What do you mean by orthogonal changes in capabilities?  Do you mean
> selinux interpreting some caps differently from the capability module?

No, just the fact that under TE, you can define the capabilities
assigned to the caller domain and to the callee domain independently and
separately, and then set up the domain transition between them.  Versus
following a fixed evolution computation based on the caller's capability
bitmasks and the file's capability bitmasks.

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

Re: [RFC v2][PATCH] selinux: enable authoritative granting of capabilities

[Serge E. Hallyn]

Quoting Stephen Smalley (sds@tycho.nsa.gov):
> On Wed, 2007-06-20 at 15:13 -0500, Serge E. Hallyn wrote:
> > Quoting Stephen Smalley (sds@tycho.nsa.gov):
> > > An alternative approach to implementing this support for authoritative
> > > granting of capabilities by SELinux would be to compute the full
> > > cap_override access vector upon exec and cap_combine it with the base
> > > capability sets, such that the task's capability bitmasks would reflect
> > > the combined capabilities authorized by the base logic and by SELinux
> > > policy.  Then the capable() hook itself would remain unchanged from the
> > > current (unpatched) code, just checking the task's capability bitmask
> > > and then checking the SELinux capability access vector as a further
> > > restriction on use.
> > > 
> > > There are two places where that computation and combination could be
> > > done: before the usual capability evolution logic is applied (by
> > > cap_bprm_apply_creds) or after it.  If before, we'd be manipulating the
> > > bprm capability bitmasks (similar to file capabilities) and then letting
> > > the usual capability evolution occur; if after, we'd be manipulating the
> > > task capability bitmasks after they have been updated by the capability
> > > module.
> > > 
> > > Observations:
> > > - This approach would make the granting of such capabilities visible in
> > > the task's capability bitmasks as returned by capget
> > > or /proc/self/status.
> > 
> > That's kind of cool, but I guess it would also lead to policy
> > reloads not fully affecting the capabilities granted to already
> > running programs.  So if you remove CAP_NET_RAW from ping_t,
> > some long-running ping (haha, insert your own better example here)
> > would continue to run with CAP_NET_RAW, right?
> 
> Suppose that you granted ping_t net_raw authoritatively via the
> following pair of rules (both required):
> # Allow ping_t to use net_raw capability; checked-on-use.
> allow ping_t self:capability net_raw;
> # Grant ping_t net_raw capability even if not suid; checked-on-exec.
> allow ping_t self:cap_override net_raw;
> 
> Now you want to revoke net_raw from ping_t (or possibly both allow rules
> were under a boolean in the first place, and you are toggling the
> boolean).  You can still remove/disable the first rule and thus revoke
> any further use of the capability.

But you can't have that take effect for non-root users (who would not
otherwise have the capability) while letting root users use it, right?

> > Was there ever any mention of just stopping the stacking with
> > capability, and just letting selinux handle all it's own capability
> > logic?  Oh, yes, (vaguely recalling) the argument was about turning
> > selinux off?  But with the authoritative capabilities logic being
> > added to selinux that would be a problem anyway, right?
> 
> That approach has several disadvantages:
> - it changes the semantic meaning of existing policies:  allow a_t
> self:capability { a b c }; changes from being an upper bound on what
> capabilities a_t can ever exercise to being a direct grant of those
> capabilities to all a_t processes.  Note for example that SELinux policy
> allows all capabilities to unconfined_t, yet ordinary user processes in
> unconfined_t can only exercise capabilities via setuid root programs
> under the current scheme, and we wouldn't want that to change wholesale.
> - it removes a protection boundary on which existing policies were
> relying:  the need to change uids or at least capability bitmasks
> provided an orthogonal protection check between processes, so it was ok
> for e.g. processes with differing capability sets to run in the same
> domain formerly (again as in unconfined_t).
> - it applies the behavior change globally rather than selectively on a
> per-domain per-capability basis (vs. having separate allow a_t
> self:cap_override rules that can specify any subset of the ones allowed
> by the capability rule).

Ok, makes sense, thanks.

> > > Those bitmasks would however still not reflect
> > > the further restrictions imposed by the SELinux capability access vector
> > > check.
> > > - This approach would enable the existing capability-based tests to
> > > provide some protection of the privileged process even apart from the
> > > SELinux checks, although such protection will still be incomplete
> > > without the SELinux checks (e.g. we'd gain separate ptrace checking
> > > based on capabilities, but still depend on selinux control over
> > > creating/relabeling-to the entrypoint type for the domain).  The extent
> > > of additional checking depends on whether we do the manipulation before
> > > or after the usual evolution logic as well; if before, we pick up the
> > > usual checking on exec; if after, we don't.
> > > - Doing the computation and combination first and then applying the
> > > usual evolution logic has a cost in flexibility as it won't support
> > > orthogonal changes in capabilities.
> > 
> > What do you mean by orthogonal changes in capabilities?  Do you mean
> > selinux interpreting some caps differently from the capability module?
> 
> No, just the fact that under TE, you can define the capabilities
> assigned to the caller domain and to the callee domain independently and
> separately, and then set up the domain transition between them.  Versus
> following a fixed evolution computation based on the caller's capability
> bitmasks and the file's capability bitmasks.

Ok, I see.

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.

Re: [RFC v2][PATCH] selinux: enable authoritative granting of capabilities

[Stephen Smalley]

On Wed, 2007-06-20 at 16:08 -0500, Serge E. Hallyn wrote:
> Quoting Stephen Smalley (sds@tycho.nsa.gov):
> > On Wed, 2007-06-20 at 15:13 -0500, Serge E. Hallyn wrote:
> > > Quoting Stephen Smalley (sds@tycho.nsa.gov):
> > > > An alternative approach to implementing this support for authoritative
> > > > granting of capabilities by SELinux would be to compute the full
> > > > cap_override access vector upon exec and cap_combine it with the base
> > > > capability sets, such that the task's capability bitmasks would reflect
> > > > the combined capabilities authorized by the base logic and by SELinux
> > > > policy.  Then the capable() hook itself would remain unchanged from the
> > > > current (unpatched) code, just checking the task's capability bitmask
> > > > and then checking the SELinux capability access vector as a further
> > > > restriction on use.
> > > > 
> > > > There are two places where that computation and combination could be
> > > > done: before the usual capability evolution logic is applied (by
> > > > cap_bprm_apply_creds) or after it.  If before, we'd be manipulating the
> > > > bprm capability bitmasks (similar to file capabilities) and then letting
> > > > the usual capability evolution occur; if after, we'd be manipulating the
> > > > task capability bitmasks after they have been updated by the capability
> > > > module.
> > > > 
> > > > Observations:
> > > > - This approach would make the granting of such capabilities visible in
> > > > the task's capability bitmasks as returned by capget
> > > > or /proc/self/status.
> > > 
> > > That's kind of cool, but I guess it would also lead to policy
> > > reloads not fully affecting the capabilities granted to already
> > > running programs.  So if you remove CAP_NET_RAW from ping_t,
> > > some long-running ping (haha, insert your own better example here)
> > > would continue to run with CAP_NET_RAW, right?
> > 
> > Suppose that you granted ping_t net_raw authoritatively via the
> > following pair of rules (both required):
> > # Allow ping_t to use net_raw capability; checked-on-use.
> > allow ping_t self:capability net_raw;
> > # Grant ping_t net_raw capability even if not suid; checked-on-exec.
> > allow ping_t self:cap_override net_raw;
> > 
> > Now you want to revoke net_raw from ping_t (or possibly both allow rules
> > were under a boolean in the first place, and you are toggling the
> > boolean).  You can still remove/disable the first rule and thus revoke
> > any further use of the capability.
> 
> But you can't have that take effect for non-root users (who would not
> otherwise have the capability) while letting root users use it, right?

True.

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

Linux user / SELinux user changes...

[Hasan Rezaul-CHR010]

 
Hi All,

If I have Linux users "root"  and "test"     and I have
SELinux users  "staff_u", and "user_u",  and 
SELinux roles  "staff_r", and "user_r"  

If I ssh into the Linux machine as test, my SELinux identity is user_u.
If I ssh into the Linux machine as root, my SELinux identity is staff_u.

Lets say I ssh into my Linux machine as Linux user "root".
"id -Z"  shows   staff_u:staff_r:staff_t

Now if I downgrade my Linux user priviledge to user "test" by using  su
as follows:

su - test
Pass: test

id -Z  =>  still shows me that I am staff_u , even though I am Linux
user "test" (Linux user test should ideally be mapped to user_u).

Is there a way for SELinux to automatically adjust/change the SELinux
user, whenever the Linux user is changed via "su"  ???

Thanks in advance,

- Rezaul.

P.S. I can appreciate why first logging in as Linux user test, and then
su to root, will still keep my SELinux user to user_u.  But just curious
if there is any flexibility in this regard ?


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

Re: Linux user / SELinux user changes...

[Ken YANG]

Hasan Rezaul-CHR010 wrote:
>  
> Hi All,
> 
> If I have Linux users "root"  and "test"     and I have
> SELinux users  "staff_u", and "user_u",  and 
> SELinux roles  "staff_r", and "user_r"  
> 
> If I ssh into the Linux machine as test, my SELinux identity is user_u.
> If I ssh into the Linux machine as root, my SELinux identity is staff_u.
> 
> Lets say I ssh into my Linux machine as Linux user "root".
> "id -Z"  shows   staff_u:staff_r:staff_t
> 
> Now if I downgrade my Linux user priviledge to user "test" by using  su
> as follows:
> 
> su - test
> Pass: test
> 
> id -Z  =>  still shows me that I am staff_u , even though I am Linux
> user "test" (Linux user test should ideally be mapped to user_u).
> 
> Is there a way for SELinux to automatically adjust/change the SELinux
> user, whenever the Linux user is changed via "su"  ???

in original selinux, su can change context, including selinux user,
but now, su can not change selinux user at all, su/pam_selinux
had been reverted for a while. if you want to switch to admin role,
you must use "newrole"

furthermore, user_r can not switch to staff_r, you must map your
linux user identity to staff_u via semanage, before you switch to
admin role. the difference between staff_u and user_u is the former
can switch to admin role, i.e. sysadm_r(root)

http://marc.info/?l=selinux&m=118121922201142&w=2

this thread maybe help you


> 
> Thanks in advance,
> 
> - Rezaul.
> 
> P.S. I can appreciate why first logging in as Linux user test, and then
> su to root, will still keep my SELinux user to user_u.  But just curious
> if there is any flexibility in this regard ?
> 
> 
> --
> 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.

Re: Linux user / SELinux user changes...

[Stephen Smalley]

On Thu, 2007-06-21 at 21:29 -0400, Hasan Rezaul-CHR010 wrote:
>  Hi All,
> 
> If I have Linux users "root"  and "test"     and I have
> SELinux users  "staff_u", and "user_u",  and 
> SELinux roles  "staff_r", and "user_r"  
> 
> If I ssh into the Linux machine as test, my SELinux identity is user_u.
> If I ssh into the Linux machine as root, my SELinux identity is staff_u.
> 
> Lets say I ssh into my Linux machine as Linux user "root".
> "id -Z"  shows   staff_u:staff_r:staff_t
> 
> Now if I downgrade my Linux user priviledge to user "test" by using  su
> as follows:
> 
> su - test
> Pass: test
> 
> id -Z  =>  still shows me that I am staff_u , even though I am Linux
> user "test" (Linux user test should ideally be mapped to user_u).
> 
> Is there a way for SELinux to automatically adjust/change the SELinux
> user, whenever the Linux user is changed via "su"  ???

In original SELinux, we intentionally chose to not change SELinux user
identity upon su; the SELinux user identity was established upon login
session creation and served as a fixed bound on the potential set of
security contexts that the user could enter for the entire session
(using newrole to change roles).

In early Fedora and RHEL (Fedora < 5?, RHEL 4) SELinux, Red Hat chose to
integrate su with SELinux by putting pam_selinux into /etc/pam.d/su.
But they later reverted that - it caused more problems than it solved.
So modern Fedora and RHEL 5 have the original SELinux behavior of
keeping them separated.

You could put pam_selinux into /etc/pam.d/su (see /etc/pam.d/login for
an example) and change your policy to allow that (see the
ifdef(`distro_rhel4' blocks in policy/modules/admin/su.if), but that
would deviate from current standard practice.

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

Re: [RFC v2][PATCH] selinux: enable authoritative granting of capabilities

[Joshua Brindle]

Stephen Smalley wrote:
> An alternative approach to implementing this support for authoritative
> granting of capabilities by SELinux would be to compute the full
> cap_override access vector upon exec and cap_combine it with the base
> capability sets, such that the task's capability bitmasks would reflect
> the combined capabilities authorized by the base logic and by SELinux
> policy.  Then the capable() hook itself would remain unchanged from the
> current (unpatched) code, just checking the task's capability bitmask
> and then checking the SELinux capability access vector as a further
> restriction on use.
> 
> There are two places where that computation and combination could be
> done: before the usual capability evolution logic is applied (by
> cap_bprm_apply_creds) or after it.  If before, we'd be manipulating the
> bprm capability bitmasks (similar to file capabilities) and then letting
> the usual capability evolution occur; if after, we'd be manipulating the
> task capability bitmasks after they have been updated by the capability
> module.
> 
> Observations:
> - This approach would make the granting of such capabilities visible in
> the task's capability bitmasks as returned by capget
> or /proc/self/status.  Those bitmasks would however still not reflect
> the further restrictions imposed by the SELinux capability access vector
> check.
> - This approach would enable the existing capability-based tests to
> provide some protection of the privileged process even apart from the
> SELinux checks, although such protection will still be incomplete
> without the SELinux checks (e.g. we'd gain separate ptrace checking
> based on capabilities, but still depend on selinux control over
> creating/relabeling-to the entrypoint type for the domain).  The extent
> of additional checking depends on whether we do the manipulation before
> or after the usual evolution logic as well; if before, we pick up the
> usual checking on exec; if after, we don't.
> - Doing the computation and combination first and then applying the
> usual evolution logic has a cost in flexibility as it won't support
> orthogonal changes in capabilities.
> 
> Thoughts?
> 

So this lets SELinux granted capabilities to migrate across execve(), 
granted the Selinux policy still has to be consulted to grant 
capabilities before use but this could result in incorrect policy being 
enforced, right? Particularly across policy reloads or boolean changes; 
this just doesn't seem as robust as the old method of deciding at time 
of use rather than time of process creation.


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