[PATCH] Define CAP_SYSLOG

[PATCH] Define CAP_SYSLOG

[Serge E. Hallyn]

Privileged syslog operations currently require CAP_SYS_ADMIN.  Split
this off into a new CAP_SYSLOG privilege which we can sanely take away
from a container through the capability bounding set.

With this patch, an lxc container can be prevented from messing with
the host's syslog (i.e. dmesg -c).

There is one downside to this patch:  If some site or distro currently
has syslogd/whatever running as a non-root user with cap_sys_admin+pe,
then it will need to be changed to run with cap_syslog+pe.  I don't
know if there are such sites, or if that concern means we should take
a different approach to introducing this change, or simply refuse this
change.

I'm also sending out corresponding patches for libcap and refpolicy, and
will whip up a man-pages patch next week.

Changelog: mar 12 2010: add selinux capability2:cap_syslog perm

Signed-off-by: Serge E. Hallyn <serue@us.ibm.com>
Acked-by: Andrew G. Morgan <morgan@kernel.org>
Acked-By: Kees Cook <kees.cook@canonical.com>
Cc: James Morris <jmorris@namei.org>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>
Cc: Stephen Smalley <sds@tycho.nsa.gov>
Cc: "Christopher J. PeBenito" <cpebenito@tresys.com>
Cc: Eric Paris <eparis@parisplace.org>
---
 include/linux/capability.h          |    7 +++++--
 security/commoncap.c                |    2 +-
 security/selinux/include/classmap.h |    2 +-
 3 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/include/linux/capability.h b/include/linux/capability.h
index 39e5ff5..837a55c 100644
--- a/include/linux/capability.h
+++ b/include/linux/capability.h
@@ -249,7 +249,6 @@ struct cpu_vfs_cap_data {
 /* Allow configuration of the secure attention key */
 /* Allow administration of the random device */
 /* Allow examination and configuration of disk quotas */
-/* Allow configuring the kernel's syslog (printk behaviour) */
 /* Allow setting the domainname */
 /* Allow setting the hostname */
 /* Allow calling bdflush() */
@@ -355,7 +354,11 @@ struct cpu_vfs_cap_data {
 
 #define CAP_MAC_ADMIN        33
 
-#define CAP_LAST_CAP         CAP_MAC_ADMIN
+/* Allow configuring the kernel's syslog (printk behaviour) */
+
+#define CAP_SYSLOG           34
+
+#define CAP_LAST_CAP         CAP_SYSLOG
 
 #define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)
 
diff --git a/security/commoncap.c b/security/commoncap.c
index 6166973..018985e 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -899,7 +899,7 @@ int cap_syslog(int type, bool from_file)
 	if (type != SYSLOG_ACTION_OPEN && from_file)
 		return 0;
 	if ((type != SYSLOG_ACTION_READ_ALL &&
-	     type != SYSLOG_ACTION_SIZE_BUFFER) && !capable(CAP_SYS_ADMIN))
+	     type != SYSLOG_ACTION_SIZE_BUFFER) && !capable(CAP_SYSLOG))
 		return -EPERM;
 	return 0;
 }
diff --git a/security/selinux/include/classmap.h b/security/selinux/include/classmap.h
index 8b32e95..f03cf56 100644
--- a/security/selinux/include/classmap.h
+++ b/security/selinux/include/classmap.h
@@ -142,7 +142,7 @@ struct security_class_mapping secclass_map[] = {
 	    "node_bind", "name_connect", NULL } },
 	{ "memprotect", { "mmap_zero", NULL } },
 	{ "peer", { "recv", NULL } },
-	{ "capability2", { "mac_override", "mac_admin", NULL } },
+	{ "capability2", { "mac_override", "mac_admin", "syslog", NULL } },
 	{ "kernel_service", { "use_as_override", "create_files_as", NULL } },
 	{ "tun_socket",
 	  { COMMON_SOCK_PERMS, NULL } },
-- 
1.6.1

[PATCH] Define CAP_SYSLOG

[Serge E. Hallyn]

Privileged syslog operations currently require CAP_SYS_ADMIN.  Split
this off into a new CAP_SYSLOG privilege which we can sanely take away
from a container through the capability bounding set.

With this patch, an lxc container can be prevented from messing with
the host's syslog (i.e. dmesg -c).

There is one downside to this patch:  If some site or distro currently
has syslogd/whatever running as a non-root user with cap_sys_admin+pe,
then it will need to be changed to run with cap_syslog+pe.  I don't
know if there are such sites, or if that concern means we should take
a different approach to introducing this change, or simply refuse this
change.

I'm also sending out corresponding patches for libcap and refpolicy, and
will whip up a man-pages patch next week.

Changelog: mar 12 2010: add selinux capability2:cap_syslog perm

Signed-off-by: Serge E. Hallyn <serue@us.ibm.com>
Acked-by: Andrew G. Morgan <morgan@kernel.org>
Acked-By: Kees Cook <kees.cook@canonical.com>
Cc: James Morris <jmorris@namei.org>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>
Cc: Stephen Smalley <sds@tycho.nsa.gov>
Cc: "Christopher J. PeBenito" <cpebenito@tresys.com>
Cc: Eric Paris <eparis@parisplace.org>
---
 include/linux/capability.h          |    7 +++++--
 security/commoncap.c                |    2 +-
 security/selinux/include/classmap.h |    2 +-
 3 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/include/linux/capability.h b/include/linux/capability.h
index 39e5ff5..837a55c 100644
--- a/include/linux/capability.h
+++ b/include/linux/capability.h
@@ -249,7 +249,6 @@ struct cpu_vfs_cap_data {
 /* Allow configuration of the secure attention key */
 /* Allow administration of the random device */
 /* Allow examination and configuration of disk quotas */
-/* Allow configuring the kernel's syslog (printk behaviour) */
 /* Allow setting the domainname */
 /* Allow setting the hostname */
 /* Allow calling bdflush() */
@@ -355,7 +354,11 @@ struct cpu_vfs_cap_data {
 
 #define CAP_MAC_ADMIN        33
 
-#define CAP_LAST_CAP         CAP_MAC_ADMIN
+/* Allow configuring the kernel's syslog (printk behaviour) */
+
+#define CAP_SYSLOG           34
+
+#define CAP_LAST_CAP         CAP_SYSLOG
 
 #define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)
 
diff --git a/security/commoncap.c b/security/commoncap.c
index 6166973..018985e 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -899,7 +899,7 @@ int cap_syslog(int type, bool from_file)
 	if (type != SYSLOG_ACTION_OPEN && from_file)
 		return 0;
 	if ((type != SYSLOG_ACTION_READ_ALL &&
-	     type != SYSLOG_ACTION_SIZE_BUFFER) && !capable(CAP_SYS_ADMIN))
+	     type != SYSLOG_ACTION_SIZE_BUFFER) && !capable(CAP_SYSLOG))
 		return -EPERM;
 	return 0;
 }
diff --git a/security/selinux/include/classmap.h b/security/selinux/include/classmap.h
index 8b32e95..f03cf56 100644
--- a/security/selinux/include/classmap.h
+++ b/security/selinux/include/classmap.h
@@ -142,7 +142,7 @@ struct security_class_mapping secclass_map[] = {
 	    "node_bind", "name_connect", NULL } },
 	{ "memprotect", { "mmap_zero", NULL } },
 	{ "peer", { "recv", NULL } },
-	{ "capability2", { "mac_override", "mac_admin", NULL } },
+	{ "capability2", { "mac_override", "mac_admin", "syslog", NULL } },
 	{ "kernel_service", { "use_as_override", "create_files_as", NULL } },
 	{ "tun_socket",
 	  { COMMON_SOCK_PERMS, NULL } },
-- 
1.6.1


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

[refpolicy] [PATCH refpolicy] add capability2:syslog perm

[Serge E. Hallyn]

CAP_SYSLOG is (hopefully) being split out from CAP_SYS_ADMIN.  This
patch adds capability2:syslog to the access vectors, and adds the
perm to a few domains which look like they'll need it.

This patch is just advisory right now - please do not apply until/unless
the corresponding kernel patch is accepted :)

Signed-off-by: Serge E. Hallyn <serue@us.ibm.com>
Cc: refpolicy at oss.tresys.com
Cc: "Christopher J. PeBenito" <cpebenito@tresys.com>
Cc: Eric Paris <eparis@parisplace.org>
Cc: Stephen Smalley <sds@tycho.nsa.gov>
---
 policy/flask/access_vectors      |    1 +
 policy/modules/admin/dmesg.te    |    1 +
 policy/modules/system/init.te    |    2 ++
 policy/modules/system/logging.te |    2 ++
 4 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/policy/flask/access_vectors b/policy/flask/access_vectors
index 6760c95..6e7af2c 100644
--- a/policy/flask/access_vectors
+++ b/policy/flask/access_vectors
@@ -428,6 +428,7 @@ class capability2
 {
 	mac_override	# unused by SELinux
 	mac_admin	# unused by SELinux
+	syslog		# used to be part of sys_admin
 }
 
 #
diff --git a/policy/modules/admin/dmesg.te b/policy/modules/admin/dmesg.te
index 36033f7..edc6aa6 100644
--- a/policy/modules/admin/dmesg.te
+++ b/policy/modules/admin/dmesg.te
@@ -16,6 +16,7 @@ init_system_domain(dmesg_t, dmesg_exec_t)
 #
 
 allow dmesg_t self:capability sys_admin;
+allow dmesg_t self:capability2 syslog;
 dontaudit dmesg_t self:capability sys_tty_config;
 
 allow dmesg_t self:process signal_perms;
diff --git a/policy/modules/system/init.te b/policy/modules/system/init.te
index 6f5dc89..f9ae18e 100644
--- a/policy/modules/system/init.te
+++ b/policy/modules/system/init.te
@@ -203,6 +203,7 @@ optional_policy(`
 
 allow initrc_t self:process { getpgid setsched setpgid setrlimit getsched };
 allow initrc_t self:capability ~{ sys_admin sys_module };
+allow initrc_t self:capability2 syslog;
 dontaudit initrc_t self:capability sys_module; # sysctl is triggering this
 allow initrc_t self:passwd rootok;
 
@@ -445,6 +446,7 @@ ifdef(`distro_gentoo',`
 ifdef(`distro_redhat',`
 	# this is from kmodule, which should get its own policy:
 	allow initrc_t self:capability sys_admin;
+	allow initrc_t self:capability2 syslog;
 
 	allow initrc_t self:process setfscreate;
 
diff --git a/policy/modules/system/logging.te b/policy/modules/system/logging.te
index f6ba06c..7eb6bd8 100644
--- a/policy/modules/system/logging.te
+++ b/policy/modules/system/logging.te
@@ -268,6 +268,7 @@ sysnet_dns_name_resolve(audisp_remote_t)
 #
 
 allow klogd_t self:capability sys_admin;
+allow klogd_t self:capability2 syslog;
 dontaudit klogd_t self:capability { sys_resource sys_tty_config };
 allow klogd_t self:process signal_perms;
 
@@ -330,6 +331,7 @@ optional_policy(`
 # sys_admin for the integrated klog of syslog-ng and metalog
 # cjp: why net_admin!
 allow syslogd_t self:capability { dac_override sys_resource sys_tty_config net_admin sys_admin chown fsetid };
+allow syslogd_t self:capability2 syslog;
 dontaudit syslogd_t self:capability sys_tty_config;
 # setpgid for metalog
 # setrlimit for syslog-ng
-- 
1.6.0.6

Re: [PATCH] Define CAP_SYSLOG

[Michael Kerrisk]

> There is one downside to this patch:  If some site or distro currently
> has syslogd/whatever running as a non-root user with cap_sys_admin+pe,
> then it will need to be changed to run with cap_syslog+pe.  I don't
> know if there are such sites, or if that concern means we should take
> a different approach to introducing this change, or simply refuse this
> change.

*If* this is a problem, would the way to address it not be to permit
syslog if the caller has *either* CAP_SYS_ADMIN or CAP_SYSLOG? (The
only weakness I see in this idea is that it fails to lighten the
hugely overlaoded CAP_SYS_ADMIN.)

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface" http://blog.man7.org/

Re: [PATCH] Define CAP_SYSLOG

[Serge E. Hallyn]

Quoting Michael Kerrisk (mtk.manpages@googlemail.com):
> > There is one downside to this patch:  If some site or distro currently
> > has syslogd/whatever running as a non-root user with cap_sys_admin+pe,
> > then it will need to be changed to run with cap_syslog+pe.  I don't
> > know if there are such sites, or if that concern means we should take
> > a different approach to introducing this change, or simply refuse this
> > change.
> 
> *If* this is a problem, would the way to address it not be to permit
> syslog if the caller has *either* CAP_SYS_ADMIN or CAP_SYSLOG? (The
> only weakness I see in this idea is that it fails to lighten the
> hugely overlaoded CAP_SYS_ADMIN.)

Which becomes a very big weakness because it won't allow a
container to be started with cap_sys_admin but not cap_syslog
in its capability bounding set.

So, if it is deemed a problem, then the alternative will be to
introduce a syslog namespace.  Container setup can then create
a new syslog namespace, and can no longer read or clear the
host's syslog.

thanks,
-serge

Re: [PATCH] Define CAP_SYSLOG

[Serge E. Hallyn]

Quoting Michael Kerrisk (mtk.manpages@googlemail.com):
> > There is one downside to this patch:  If some site or distro currently
> > has syslogd/whatever running as a non-root user with cap_sys_admin+pe,
> > then it will need to be changed to run with cap_syslog+pe.  I don't
> > know if there are such sites, or if that concern means we should take
> > a different approach to introducing this change, or simply refuse this
> > change.
> 
> *If* this is a problem, would the way to address it not be to permit
> syslog if the caller has *either* CAP_SYS_ADMIN or CAP_SYSLOG? (The
> only weakness I see in this idea is that it fails to lighten the
> hugely overlaoded CAP_SYS_ADMIN.)

Which becomes a very big weakness because it won't allow a
container to be started with cap_sys_admin but not cap_syslog
in its capability bounding set.

So, if it is deemed a problem, then the alternative will be to
introduce a syslog namespace.  Container setup can then create
a new syslog namespace, and can no longer read or clear the
host's syslog.

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: [PATCH] Define CAP_SYSLOG

[Matthew Helsley]

On Sat, Mar 13, 2010 at 10:35 PM, Serge E. Hallyn <serue@us.ibm.com> wrote:
> Quoting Michael Kerrisk (mtk.manpages@googlemail.com):
>> > There is one downside to this patch:  If some site or distro currently
>> > has syslogd/whatever running as a non-root user with cap_sys_admin+pe,
>> > then it will need to be changed to run with cap_syslog+pe.  I don't
>> > know if there are such sites, or if that concern means we should take
>> > a different approach to introducing this change, or simply refuse this
>> > change.
>>
>> *If* this is a problem, would the way to address it not be to permit
>> syslog if the caller has *either* CAP_SYS_ADMIN or CAP_SYSLOG? (The
>> only weakness I see in this idea is that it fails to lighten the
>> hugely overlaoded CAP_SYS_ADMIN.)
>
> Which becomes a very big weakness because it won't allow a
> container to be started with cap_sys_admin but not cap_syslog
> in its capability bounding set.
>
> So, if it is deemed a problem, then the alternative will be to
> introduce a syslog namespace.  Container setup can then create
> a new syslog namespace, and can no longer read or clear the
> host's syslog.
>
> thanks,
> -serge

Would it make sense to warn once when CAP_SYS_ADMIN permits what
CAP_SYSLOG will be used for in the future? Something like:

-            type != SYSLOG_ACTION_SIZE_BUFFER) && !capable(CAP_SYS_ADMIN))
+            type != SYSLOG_ACTION_SIZE_BUFFER) &&
!(capable(CAP_SYSLOG)||capable(CAP_SYS_ADMIN))) {
+             WARN_ONCE(capable(CAP_SYS_ADMIN) &&
!capable(CAP_SYSLOG), "CAP_SYS_ADMIN will not permit syslog
configuration in the near future. Please switch your code to
CAP_SYSLOG\n");
               return -EPERM;
+        }
       return 0;

After a period of time allowing userspace apps to transition to
CAP_SYSLOG remove the CAP_SYS_ADMIN portions. Of course this won't fix
containers for that transition period but it would avoid a sudden
change of what CAP_SYS_ADMIN allows.

> So, if it is deemed a problem, then the alternative will be to
> introduce a syslog namespace.  Container setup can then create
> a new syslog namespace, and can no longer read or clear the
> host's syslog.

Yup, this is also an option. Possibly better as it doesn't involved
changing the meaning of a overly-[ab]used capability bit and wouldn't
require a transition period.

Cheers.
    -Matt Helsley

Re: [PATCH] Define CAP_SYSLOG

[Serge E. Hallyn]

Quoting Matthew Helsley (matt.helsley@gmail.com):
> On Sat, Mar 13, 2010 at 10:35 PM, Serge E. Hallyn <serue@us.ibm.com> wrote:
> > Quoting Michael Kerrisk (mtk.manpages@googlemail.com):
> >> > There is one downside to this patch:  If some site or distro currently
> >> > has syslogd/whatever running as a non-root user with cap_sys_admin+pe,
> >> > then it will need to be changed to run with cap_syslog+pe.  I don't
> >> > know if there are such sites, or if that concern means we should take
> >> > a different approach to introducing this change, or simply refuse this
> >> > change.
> >>
> >> *If* this is a problem, would the way to address it not be to permit
> >> syslog if the caller has *either* CAP_SYS_ADMIN or CAP_SYSLOG? (The
> >> only weakness I see in this idea is that it fails to lighten the
> >> hugely overlaoded CAP_SYS_ADMIN.)
> >
> > Which becomes a very big weakness because it won't allow a
> > container to be started with cap_sys_admin but not cap_syslog
> > in its capability bounding set.
> >
> > So, if it is deemed a problem, then the alternative will be to
> > introduce a syslog namespace.  Container setup can then create
> > a new syslog namespace, and can no longer read or clear the
> > host's syslog.
> >
> > thanks,
> > -serge
> 
> Would it make sense to warn once when CAP_SYS_ADMIN permits what
> CAP_SYSLOG will be used for in the future? Something like:
> 
> -            type != SYSLOG_ACTION_SIZE_BUFFER) && !capable(CAP_SYS_ADMIN))
> +            type != SYSLOG_ACTION_SIZE_BUFFER) &&
> !(capable(CAP_SYSLOG)||capable(CAP_SYS_ADMIN))) {
> +             WARN_ONCE(capable(CAP_SYS_ADMIN) &&
> !capable(CAP_SYSLOG), "CAP_SYS_ADMIN will not permit syslog
> configuration in the near future. Please switch your code to
> CAP_SYSLOG\n");
>                return -EPERM;
> +        }
>        return 0;

Good idea - though I'd prefer to WARN_ONCE and then deny :)  If we log
and allow, the log msg will be ignored.

> After a period of time allowing userspace apps to transition to
> CAP_SYSLOG remove the CAP_SYS_ADMIN portions. Of course this won't fix
> containers for that transition period but it would avoid a sudden
> change of what CAP_SYS_ADMIN allows.
> 
> > So, if it is deemed a problem, then the alternative will be to
> > introduce a syslog namespace.  Container setup can then create
> > a new syslog namespace, and can no longer read or clear the
> > host's syslog.
> 
> Yup, this is also an option. Possibly better as it doesn't involved
> changing the meaning of a overly-[ab]used capability bit and wouldn't
> require a transition period.

Still I can definately see a case where you want the container to
be in the host's syslog for simplicity, but not be able to clear it.

-serge

Re: [PATCH] Define CAP_SYSLOG

[Serge E. Hallyn]

Quoting Matthew Helsley (matt.helsley@gmail.com):
> On Sat, Mar 13, 2010 at 10:35 PM, Serge E. Hallyn <serue@us.ibm.com> wrote:
> > Quoting Michael Kerrisk (mtk.manpages@googlemail.com):
> >> > There is one downside to this patch:  If some site or distro currently
> >> > has syslogd/whatever running as a non-root user with cap_sys_admin+pe,
> >> > then it will need to be changed to run with cap_syslog+pe.  I don't
> >> > know if there are such sites, or if that concern means we should take
> >> > a different approach to introducing this change, or simply refuse this
> >> > change.
> >>
> >> *If* this is a problem, would the way to address it not be to permit
> >> syslog if the caller has *either* CAP_SYS_ADMIN or CAP_SYSLOG? (The
> >> only weakness I see in this idea is that it fails to lighten the
> >> hugely overlaoded CAP_SYS_ADMIN.)
> >
> > Which becomes a very big weakness because it won't allow a
> > container to be started with cap_sys_admin but not cap_syslog
> > in its capability bounding set.
> >
> > So, if it is deemed a problem, then the alternative will be to
> > introduce a syslog namespace.  Container setup can then create
> > a new syslog namespace, and can no longer read or clear the
> > host's syslog.
> >
> > thanks,
> > -serge
> 
> Would it make sense to warn once when CAP_SYS_ADMIN permits what
> CAP_SYSLOG will be used for in the future? Something like:
> 
> -            type != SYSLOG_ACTION_SIZE_BUFFER) && !capable(CAP_SYS_ADMIN))
> +            type != SYSLOG_ACTION_SIZE_BUFFER) &&
> !(capable(CAP_SYSLOG)||capable(CAP_SYS_ADMIN))) {
> +             WARN_ONCE(capable(CAP_SYS_ADMIN) &&
> !capable(CAP_SYSLOG), "CAP_SYS_ADMIN will not permit syslog
> configuration in the near future. Please switch your code to
> CAP_SYSLOG\n");
>                return -EPERM;
> +        }
>        return 0;

Good idea - though I'd prefer to WARN_ONCE and then deny :)  If we log
and allow, the log msg will be ignored.

> After a period of time allowing userspace apps to transition to
> CAP_SYSLOG remove the CAP_SYS_ADMIN portions. Of course this won't fix
> containers for that transition period but it would avoid a sudden
> change of what CAP_SYS_ADMIN allows.
> 
> > So, if it is deemed a problem, then the alternative will be to
> > introduce a syslog namespace.  Container setup can then create
> > a new syslog namespace, and can no longer read or clear the
> > host's syslog.
> 
> Yup, this is also an option. Possibly better as it doesn't involved
> changing the meaning of a overly-[ab]used capability bit and wouldn't
> require a transition period.

Still I can definately see a case where you want the container to
be in the host's syslog for simplicity, but not be able to clear it.

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

Console Login and SSH Login Security Contexts...

[Hasan Rezaul-CHR010]

Hi All,

I know there was a huge email thread recently regarding obtaining
correct security context after SSH-login, but I didn't really get the
answer I need from that thread. So hoping someone can help me...

I work on a 2.6.27 Linux system, where there are two partitions. A "/"
partition where all the active software runs, and an "/inactive"
partition where we download new software. 

During a software upgrade procedure, we populate the "/inactive"
partition with new software. 
We also have selinux policies loaded up on the /inactive side (so
/inactive/etc/selinux/strict/*), 
and I use the "setfiles" command to label the entire /inactive partition
correctly. 
and then we do a reboot and flip the partitions, so that the previous
/inactive side now becomes the "/" side, and the new software runs.


My SELinux user and login configuration is as below:


root@hapWibbSc2:~# semanage user -l  
                Labeling   MLS/       MLS/                          
SELinux User    Prefix     MCS Level  MCS Range
SELinux Roles

root            sysadm     s0         s0-s15:c0.c255
staff_r sysadm_r
staff_u         staff      s0         s0-s15:c0.c255
staff_r sysadm_r
sysadm_u        sysadm     s0         s0-s15:c0.c255
sysadm_r
system_u        user       s0         s0-s15:c0.c255
system_r
unconfined_u    unconfined s0         s0-s15:c0.c255
unconfined_r
user_u          user       s0         s0
user_r



root@hapWibbSc2:~# semanage login -l                           
Login Name      SELinux User		  MLS/MCS Range

root            root                  s0-s15:c0.c255                 
admin           staff_u               s0                          
system_u        system_u              s0-s15:c0.c255    
__default__     user_u                s0             
                   

What I would like to see is:

when Linux User = 'root' logs into the console or through SSH, I would
like to see context = root:sysadm_r:sysadm_t
when Linux User = 'admin' logs into the console or through SSH, I would
like to see context = staff_u:staff_r:staff_t
when Linux User = 'Test' logs into the console or through SSH, I would
like to see context = user_u:user_r:user_t


After the software_upgrade (when the filesystem has already been labeled
correctly, and after the reboot, I would expect the "login" process and
the "sshd" process to run under the correct context
(system_u:system_r:login_exec_t), (system_u:system_r:sshd_exec_t).  But
I don't  :-(  I see them both running as  system_u:system_r:kernel_t
!!!  This tells me that the domain transitions during the init sequence
perhaps didn't go smoothly ?

And as a result, when each of the users login to the console or through
SSH, they get a wrong security context like staff_u:staff_r:insmod_t
!!!

Note: If the Linux machine is reboot ONE MORE TIME, then the 'login' and
'sshd' processes run in the correct context, and from that point on,
each user does get the security context as desired !  But in my
production system, I cant afford to have a second reboot due to timing
contraints  :-(  And I honestly don't understand why another reboot
would be necessary, considering the filesystem was already labeled and
the node was already reboot once... Why the need for this extra reboot
to set things right ? Besides, this additional reboot is NOT relabeling
anything, which means the labelling during the previous bootup was
fine...


QUESTIONS
==========

1. Any pointers as to what may be happenning ? Why processes are running
in wrong context after the first reboot ?
2. What does an additional (2nd) reboot do, that gets the processes
running in the correct context ?
3. Is there something I can do (other than 2nd reboot)  perhaps through
a script that would allow the 'login' and 'sshd' processes to restart in
the correct context ? Perhaps the "run_init" command ??
4. Anyway I can force the domain transitions to occur correctly ?
5. What is a typical sequence of domain transitions anyway during a
typical Linux bootup ?


The strange thing is, the software upgrade procedure (as described
above) and login context setting used to work just fine in conjunction
with my selinux policies, and users would obtain the correct security
contexts after loggin in... And this used to work just fine in the
previous software release after just the first reboot. But in our new
software release, this behaviour seems to have changed  :-(  But there
was no real change to selinux policies, so trying to understand what
happened??  Any pointers would be greatly appreciated. Thank You  :-)


R.H.



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

Format of file_contexts file

[Hasan Rezaul-CHR010]

Hi All,

My Linux system has a few product-specific directories like  /data,
/inactive,  /repl

The default selinux policy would obviously not know how to label these
directories the way I want, because these are not standard linux
directories. If I want to label these directories a certain way... For
example, suppose I want to label all the above directories as var_t,
can I simply add a few lines to the below two files, and then perform
relabel ? 

/etc/selinux/strict/contexts/files/file_contexts
/etc/selinux/strict/modules/active/file_contexts

- Is it okay to directly edit those files, or are the above two files
auto-generated ?
- If editing the files is okay, then is it okay to stick lines in
anywhere, or must I follow some kind of convention ?
- or is there a more recommended way to control how those
product-specific directories get labeled ?

- I have actually stuck some lines manually in the middle of the above
two files, and for the most part it seems to work. But every once in a
while, I see other directories not getting labeled correctly. Is it
because the contents of these files have to be in a certain order ? 

Thanks in advance for your help,

R.H.



--
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: Console Login and SSH Login Security Contexts...

[Christopher J. PeBenito]

On 10/31/10 18:36, Hasan Rezaul-CHR010 wrote:
> Hi All,
> 
> I know there was a huge email thread recently regarding obtaining
> correct security context after SSH-login, but I didn't really get the
> answer I need from that thread. So hoping someone can help me...
[...]
> After the software_upgrade (when the filesystem has already been labeled
> correctly, and after the reboot, I would expect the "login" process and
> the "sshd" process to run under the correct context
> (system_u:system_r:login_exec_t), (system_u:system_r:sshd_exec_t).  But
> I don't  :-(  I see them both running as  system_u:system_r:kernel_t
> !!!  This tells me that the domain transitions during the init sequence
> perhaps didn't go smoothly ?

This is the first problem.  It sounds like your init program (typically
/sbin/init) is not labeled correctly, which means you don't transition
out of kernel_t when init runs, meaning anything that starts up from
init/init scripts will almost certainly have the wrong context.  The
init program should be init_exec_t.  I would expect sshd to have the
sshd_t domain and local login would be local_login_t (getty processes
getty_t).


-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.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: Format of file_contexts file

[Christopher J. PeBenito]

On 11/01/10 01:27, Hasan Rezaul-CHR010 wrote:
> Hi All,
> 
> My Linux system has a few product-specific directories like  /data,
> /inactive,  /repl
> 
> The default selinux policy would obviously not know how to label these
> directories the way I want, because these are not standard linux
> directories. If I want to label these directories a certain way... For
> example, suppose I want to label all the above directories as var_t,
> can I simply add a few lines to the below two files, and then perform
> relabel ? 
> 
> /etc/selinux/strict/contexts/files/file_contexts
> /etc/selinux/strict/modules/active/file_contexts
> 
> - Is it okay to directly edit those files, or are the above two files
> auto-generated ?
> - If editing the files is okay, then is it okay to stick lines in
> anywhere, or must I follow some kind of convention ?
> - or is there a more recommended way to control how those
> product-specific directories get labeled ?
> 
> - I have actually stuck some lines manually in the middle of the above
> two files, and for the most part it seems to work. But every once in a
> while, I see other directories not getting labeled correctly. Is it
> because the contents of these files have to be in a certain order ? 

These files are generated from the file contexts in the modules and the
local file contexts.  You should add your file contexts to a custom
policy module or use 'semanage fcontext' to add file contexts to the
local configuration.  Then when these files are regenerated, your file
contexts will be included.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.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: Console Login and SSH Login Security Contexts...

[Hasan Rezaul-CHR010]

-----Original Message-----
From: Christopher J. PeBenito [mailto:cpebenito@tresys.com] 
Sent: Monday, November 01, 2010 11:00 AM
To: Hasan Rezaul-CHR010
Cc: Stephen Smalley; SELinux
Subject: Re: Console Login and SSH Login Security Contexts...

On 10/31/10 18:36, Hasan Rezaul-CHR010 wrote:
> Hi All,
> 
> I know there was a huge email thread recently regarding obtaining 
> correct security context after SSH-login, but I didn't really get the 
> answer I need from that thread. So hoping someone can help me...
[...]
> After the software_upgrade (when the filesystem has already been 
> labeled correctly, and after the reboot, I would expect the "login" 
> process and the "sshd" process to run under the correct context 
> (system_u:system_r:login_exec_t), (system_u:system_r:sshd_exec_t).  
> But I don't  :-(  I see them both running as  
> system_u:system_r:kernel_t !!!  This tells me that the domain 
> transitions during the init sequence perhaps didn't go smoothly ?

This is the first problem.  It sounds like your init program (typically
/sbin/init) is not labeled correctly, which means you don't transition
out of kernel_t when init runs, meaning anything that starts up from
init/init scripts will almost certainly have the wrong context.  The
init program should be init_exec_t.  I would expect sshd to have the
sshd_t domain and local login would be local_login_t (getty processes
getty_t).


--
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com


Thanks Chris,

It seems that my  /sbin/init  program  is infact labeled correctly as
(system_u:object_r:init_exec_t).

But the sshd and login processes are still running in the  kernel_t
domain  :-(

As I mentioned, doing a second reboot, does make everything run as its
supposed to ?!? Like I said, I cant really afford this extra reboot due
to timing constraints.
- Is there anything I can do via script to set things right ?
- Can I force the domain of the sshd and login processes to change to
sshd_t and local_login_t.
- I am guessing there are other init processes that are also running in
the wrong domain! Is there anything I can do to fix all such processes
in one shot without requiring a reboot ?

Also, in my previous software releases (where we had older Linux 2.6.21,
and older selinux packages with Fedora base policy), we never had this
problem.
But in my new software release (with Linux 2.6.27, and with refpolicy as
a starting base), we are seeing this weird problem.

Any other suggestions ? Anything else we can do to ensure that the
domain transitions happen properly after the first reboot ?
What about using the "run_init" command ? Is that advisable ?  What
other init processes should we check to verify their running domain ?

Thanks as always,

R.H.


--
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: Console Login and SSH Login Security Contexts...

[HarryCiao]

[-- Attachment #1: Type: text/plain, Size: 4639 bytes --]


Hi R. H.

Please see my embedded answers.

> Subject: RE: Console Login and SSH Login  Security Contexts...
> Date: Mon, 1 Nov 2010 17:11:35 -0400
> From: CHR010@motorola.com
> To: cpebenito@tresys.com
> CC: sds@epoch.ncsc.mil; selinux@tycho.nsa.gov; XLIN1@motorola.com
> 
> 
> -----Original Message-----
> From: Christopher J. PeBenito [mailto:cpebenito@tresys.com] 
> Sent: Monday, November 01, 2010 11:00 AM
> To: Hasan Rezaul-CHR010
> Cc: Stephen Smalley; SELinux
> Subject: Re: Console Login and SSH Login Security Contexts...
> 
> On 10/31/10 18:36, Hasan Rezaul-CHR010 wrote:
> > Hi All,
> > 
> > I know there was a huge email thread recently regarding obtaining 
> > correct security context after SSH-login, but I didn't really get the 
> > answer I need from that thread. So hoping someone can help me...
> [...]
> > After the software_upgrade (when the filesystem has already been 
> > labeled correctly, and after the reboot, I would expect the "login" 
> > process and the "sshd" process to run under the correct context 
> > (system_u:system_r:login_exec_t), (system_u:system_r:sshd_exec_t).  
> > But I don't  :-(  I see them both running as  
> > system_u:system_r:kernel_t !!!  This tells me that the domain 
> > transitions during the init sequence perhaps didn't go smoothly ?
> 
> This is the first problem.  It sounds like your init program (typically
> /sbin/init) is not labeled correctly, which means you don't transition
> out of kernel_t when init runs, meaning anything that starts up from
> init/init scripts will almost certainly have the wrong context.  The
> init program should be init_exec_t.  I would expect sshd to have the
> sshd_t domain and local login would be local_login_t (getty processes
> getty_t).
> 
> 
> --
> Chris PeBenito
> Tresys Technology, LLC
> www.tresys.com | oss.tresys.com
> 
> 
> Thanks Chris,
> 
> It seems that my  /sbin/init  program  is infact labeled correctly as
> (system_u:object_r:init_exec_t).
> 
> But the sshd and login processes are still running in the  kernel_t
> domain  :-(
> 

If everything is fine, the init program should run in the init_t domain, and its previous domain is kernel_t, which we could observe from /proc/1/attr/*:

root@qemu-host:/root> cat /proc/1/attr/current 
system_u:system_r:init_t:s0-s15:c0.c1023
root@qemu-host:/root> 
root@qemu-host:/root> cat /proc/1/attr/prev    
system_u:system_r:kernel_t:s15:c0.c1023
root@qemu-host:/root> 

If the init on your system remains in the kernel_t, nearly no process on your system would ever run in the correct domain...

> As I mentioned, doing a second reboot, does make everything run as its
> supposed to ?!? 


Well, I am wondering what package your init program comes from, if it is sysvinit, then I guess we would have to enable the WITH_SELINUX compile option, so that the init program could detect if SELinux is ever supported by kernel. If yes, it would try to mount selinuxfs and then load the SELinux policy through /selinux/load and then reload itself to ensure it is running in the correct domain.

I am not sure, but for me now all I can guess is that a second reboot sounds well like the init program would get a chance to reload itself as described above. See if the updated init program has the same behavior as it used to have.

I could be wrong :-P

Hope everything works out for you!

Cheers,
Harry


> Like I said, I cant really afford this extra reboot due
> to timing constraints.
> - Is there anything I can do via script to set things right ?
> - Can I force the domain of the sshd and login processes to change to
> sshd_t and local_login_t.
> - I am guessing there are other init processes that are also running in
> the wrong domain! Is there anything I can do to fix all such processes
> in one shot without requiring a reboot ?
> 
> Also, in my previous software releases (where we had older Linux 2.6.21,
> and older selinux packages with Fedora base policy), we never had this
> problem.
> But in my new software release (with Linux 2.6.27, and with refpolicy as
> a starting base), we are seeing this weird problem.
> 
> Any other suggestions ? Anything else we can do to ensure that the
> domain transitions happen properly after the first reboot ?
> What about using the "run_init" command ? Is that advisable ?  What
> other init processes should we check to verify their running domain ?
> 
> Thanks as always,
> 
> R.H.
> 
> 
> --
> 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.
 		 	   		  

[-- Attachment #2: Type: text/html, Size: 5490 bytes --]

Re: Console Login and SSH Login Security Contexts...

[Christopher J. PeBenito]

On 11/01/10 17:11, Hasan Rezaul-CHR010 wrote:
> 
> -----Original Message-----
> From: Christopher J. PeBenito [mailto:cpebenito@tresys.com] 
> Sent: Monday, November 01, 2010 11:00 AM
> To: Hasan Rezaul-CHR010
> Cc: Stephen Smalley; SELinux
> Subject: Re: Console Login and SSH Login Security Contexts...
> 
> On 10/31/10 18:36, Hasan Rezaul-CHR010 wrote:
>> Hi All,
>>
>> I know there was a huge email thread recently regarding obtaining 
>> correct security context after SSH-login, but I didn't really get the 
>> answer I need from that thread. So hoping someone can help me...
> [...]
>> After the software_upgrade (when the filesystem has already been 
>> labeled correctly, and after the reboot, I would expect the "login" 
>> process and the "sshd" process to run under the correct context 
>> (system_u:system_r:login_exec_t), (system_u:system_r:sshd_exec_t).  
>> But I don't  :-(  I see them both running as  
>> system_u:system_r:kernel_t !!!  This tells me that the domain 
>> transitions during the init sequence perhaps didn't go smoothly ?
> 
> This is the first problem.  It sounds like your init program (typically
> /sbin/init) is not labeled correctly, which means you don't transition
> out of kernel_t when init runs, meaning anything that starts up from
> init/init scripts will almost certainly have the wrong context.  The
> init program should be init_exec_t.  I would expect sshd to have the
> sshd_t domain and local login would be local_login_t (getty processes
> getty_t).
> 

> Thanks Chris,
> 
> It seems that my  /sbin/init  program  is infact labeled correctly as
> (system_u:object_r:init_exec_t).
> 
> But the sshd and login processes are still running in the  kernel_t
> domain  :-(
> 
> As I mentioned, doing a second reboot, does make everything run as its
> supposed to ?!? Like I said, I cant really afford this extra reboot due
> to timing constraints.
> - Is there anything I can do via script to set things right ?
> - Can I force the domain of the sshd and login processes to change to
> sshd_t and local_login_t.
> - I am guessing there are other init processes that are also running in
> the wrong domain! Is there anything I can do to fix all such processes
> in one shot without requiring a reboot ?
> 
> Also, in my previous software releases (where we had older Linux 2.6.21,
> and older selinux packages with Fedora base policy), we never had this
> problem.
> But in my new software release (with Linux 2.6.27, and with refpolicy as
> a starting base), we are seeing this weird problem.
> 
> Any other suggestions ? Anything else we can do to ensure that the
> domain transitions happen properly after the first reboot ?
> What about using the "run_init" command ? Is that advisable ?  What
> other init processes should we check to verify their running domain ?

Is there a .autorelabel or something similar happening during the first
boot?  If the upgrade is not writing files with the correct label, then
the first boot would not have correct transitions, but the second would
have the right transitions because the labels on disk were fixed by the
autorelabel.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.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: Console Login and SSH Login Security Contexts...

[Hasan Rezaul-CHR010]

 

-----Original Message-----
From: Christopher J. PeBenito [mailto:cpebenito@tresys.com] 
Sent: Tuesday, November 02, 2010 8:37 AM
To: Hasan Rezaul-CHR010
Cc: Stephen Smalley; SELinux; Lin Xuejun-XLIN1
Subject: Re: Console Login and SSH Login Security Contexts...

On 11/01/10 17:11, Hasan Rezaul-CHR010 wrote:
> 
> -----Original Message-----
> From: Christopher J. PeBenito [mailto:cpebenito@tresys.com]
> Sent: Monday, November 01, 2010 11:00 AM
> To: Hasan Rezaul-CHR010
> Cc: Stephen Smalley; SELinux
> Subject: Re: Console Login and SSH Login Security Contexts...
> 
> On 10/31/10 18:36, Hasan Rezaul-CHR010 wrote:
>> Hi All,
>>
>> I know there was a huge email thread recently regarding obtaining 
>> correct security context after SSH-login, but I didn't really get the

>> answer I need from that thread. So hoping someone can help me...
> [...]
>> After the software_upgrade (when the filesystem has already been 
>> labeled correctly, and after the reboot, I would expect the "login"
>> process and the "sshd" process to run under the correct context 
>> (system_u:system_r:login_exec_t), (system_u:system_r:sshd_exec_t).
>> But I don't  :-(  I see them both running as 
>> system_u:system_r:kernel_t !!!  This tells me that the domain 
>> transitions during the init sequence perhaps didn't go smoothly ?
> 
> This is the first problem.  It sounds like your init program 
> (typically
> /sbin/init) is not labeled correctly, which means you don't transition

> out of kernel_t when init runs, meaning anything that starts up from 
> init/init scripts will almost certainly have the wrong context.  The 
> init program should be init_exec_t.  I would expect sshd to have the 
> sshd_t domain and local login would be local_login_t (getty processes 
> getty_t).
> 

> Thanks Chris,
> 
> It seems that my  /sbin/init  program  is infact labeled correctly as 
> (system_u:object_r:init_exec_t).
> 
> But the sshd and login processes are still running in the  kernel_t 
> domain  :-(
> 
> As I mentioned, doing a second reboot, does make everything run as its

> supposed to ?!? Like I said, I cant really afford this extra reboot 
> due to timing constraints.
> - Is there anything I can do via script to set things right ?
> - Can I force the domain of the sshd and login processes to change to 
> sshd_t and local_login_t.
> - I am guessing there are other init processes that are also running 
> in the wrong domain! Is there anything I can do to fix all such 
> processes in one shot without requiring a reboot ?
> 
> Also, in my previous software releases (where we had older Linux 
> 2.6.21, and older selinux packages with Fedora base policy), we never 
> had this problem.
> But in my new software release (with Linux 2.6.27, and with refpolicy 
> as a starting base), we are seeing this weird problem.
> 
> Any other suggestions ? Anything else we can do to ensure that the 
> domain transitions happen properly after the first reboot ?
> What about using the "run_init" command ? Is that advisable ?  What 
> other init processes should we check to verify their running domain ?

Is there a .autorelabel or something similar happening during the first
boot?  If the upgrade is not writing files with the correct label, then
the first boot would not have correct transitions, but the second would
have the right transitions because the labels on disk were fixed by the
autorelabel.

--
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com



Thanks Again Chris,

There is no  .autorelabel being used, (because I didn't want an
additional reboot after the autorelabel). What I did was, after the
/inactive  side was populated with software, and the selinux policies
were in place, I used the  "setfiles" command to label the  /inactive
side. The exact command I used is:

  /sbin/setfiles -r /inactive
/inactive/etc/selinux/strict/contexts/files/file_contexts /inactive

After this I expect the  /inactive  side to be labeled appropriately.

After this command, I then do a reboot (which makes the /inactive side
the new "/" side), and I expect all the services and processes to start
up in the correct context... 

This procedure used to work fine in my older software releases. In the
newer software release, not sure why its not working as before. In the
new software release, when I do an additional 2nd reboot, then only
things start up correctly  :-( 

This is why I am wondering if there are any commands I can run after the
1st reboot, that will correct any context problems ? 


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