Stephen Smalley | 4 Jan 21:34 2010
Picon

Re: CentOS 5.4 nfs home directories + cron

On Mon, 2009-12-21 at 15:11 +0000, Tom Boland wrote:
> Hi there,
> 
> I've been battling with this, but don't seem to have much luck.  I've 
> added a default file context for the crontabs in /var/spool/crontab, but 
> this doesn't seem to be honoured.  I've also added rules to allow 
> crontab to transition to the user_t type, but it's not choosing to do 
> so.  I also get permission denied when attempting to set the context 
> with the -s option to crontab.   I'm really confused about this.  Here 
> are my rules so far.

Any errors in /var/log/cron?
Any AVC messages in /var/log/audit/audit.log or /var/log/messages?

> ================================================================
> 
> module cronusertr 1.0;
> 
> require {
>     type crond_t;
>     type user_crontab_t;
>     type nfs_t;
>     type user_t;
>     class file { getattr read write execute unlink create lock 
> relabelfrom relabelto rename entrypoint };
>     class dir { add_name remove_name reparent search rmdir };
>     class process { transition };
> };
> 
> allow crond_t nfs_t:file {getattr read write execute unlink create lock 
(Continue reading)

Stephen Smalley | 4 Jan 22:11 2010
Picon

Re: [RFC PATCH v3] selinux: Fix security_compute_av() to not return unknown class errors when in permissive mode

On Fri, 2009-12-18 at 13:30 -0500, Paul Moore wrote:
> It is possible security_compute_av() to return -EINVAL, even when in
> permissive mode, due to unknown object classes and SIDs.  This patch fixes
> this by doing away with the return value for security_compute_av() and
> treating unknown classes and SIDs as permission denials.
> 
> NOTE: This patch has only been compile tested, and is only intended for
> review.  However, if someone wants to give it a try I would appreciate it
> as my time is somewhat limited since I'm technically on "vacation" as of a
> few hours ago :)
> 
> Reported-by: Andrew Worsley <amworsley@...>
> Signed-off-by: Paul Moore <paul.moore@...>

NAK.

Sorry, but I think we need to reconsider this patch, as separating the
initialization of the avd from the remainder of the computation inside
of context_struct_compute_av is fragile, as is separating the printk
error message from the actual error checking (and allow_unknown isn't
relevant in that particular case - we have already covered it after we
unmap the class).

> ---
>  security/selinux/avc.c              |   14 ++--
>  security/selinux/include/security.h |    8 +-
>  security/selinux/selinuxfs.c        |    4 +
>  security/selinux/ss/services.c      |  113 +++++++++++++----------------------
>  4 files changed, 54 insertions(+), 85 deletions(-)
> 
(Continue reading)

Stephen Smalley | 4 Jan 22:36 2010
Picon

Re: Apparent memory leak in libselinux

On Wed, 2009-12-30 at 16:32 -0800, Ed Swierk wrote:
> When I run the following on a F12 system booted with selinux=0, the
> tcmalloc heap checker complains about a leak somewhere in libselinux:
> 
> $ HEAPCHECK=normal LD_PRELOAD=/usr/lib64/libtcmalloc.so.0
> /usr/bin/python -c 'import _ssl'
> 
> Leak check _main_ detected leaks of 120 bytes in 1 objects
> The 1 largest leaks:
> Leak of 120 bytes in 1 objects allocated from:
>         <at>  0x3bf9866589 _IO_getdelim
>         <at>  0x3bfb40ca53 set_selinuxmnt
>         <at>  0x3bfb414fe6 string_to_security_class
>         <at>  0x3bfb404cdb _init
>         <at>  0x7fff4bdfa8ed 0x00007fff4bdfa8ed
> 
> No leak is detected when I run this with selinux enabled. My system
> has libselinux-2.0.87-1.fc12 installed.

Likely introduced by Eric's short cut for checking /proc/filesystems and
bailing immediately in the non-selinux case.  Try this:

diff --git a/libselinux/src/init.c b/libselinux/src/init.c
index ecb3199..4d010dc 100644
--- a/libselinux/src/init.c
+++ b/libselinux/src/init.c
 <at>  <at>  -59,8 +59,10  <at>  <at>  static void init_selinuxmnt(void)
 	}
 	fclose(fp);

(Continue reading)

Paul Moore | 4 Jan 22:44 2010
Picon

Re: [RFC PATCH v3] selinux: Fix security_compute_av() to not return unknown class errors when in permissive mode

On Monday 04 January 2010 04:11:37 pm Stephen Smalley wrote:
> On Fri, 2009-12-18 at 13:30 -0500, Paul Moore wrote:
> > It is possible security_compute_av() to return -EINVAL, even when in
> > permissive mode, due to unknown object classes and SIDs.  This patch
> > fixes this by doing away with the return value for security_compute_av()
> > and treating unknown classes and SIDs as permission denials.
> >
> > NOTE: This patch has only been compile tested, and is only intended for
> > review.  However, if someone wants to give it a try I would appreciate it
> > as my time is somewhat limited since I'm technically on "vacation" as of
> > a few hours ago :)
> >
> > Reported-by: Andrew Worsley <amworsley@...>
> > Signed-off-by: Paul Moore <paul.moore@...>
> 
> NAK.
> 
> Sorry, but I think we need to reconsider this patch, as separating the
> initialization of the avd from the remainder of the computation inside
> of context_struct_compute_av is fragile, as is separating the printk
> error message from the actual error checking (and allow_unknown isn't
> relevant in that particular case - we have already covered it after we
> unmap the class).

Okay, no problem, you know these bits of code far better than I do.

However, since I seem to keep missing the mark here some very explicit 
directions on the fix you would like to see would be helpful (I thought I had 
followed your previous suggestions but evidently I was off) or feel free to 
cobble something up yourself ... ;)
(Continue reading)

Ed Swierk | 4 Jan 23:49 2010

Re: Apparent memory leak in libselinux

On Mon, Jan 4, 2010 at 1:36 PM, Stephen Smalley <sds <at> tycho.nsa.gov> wrote:
> Likely introduced by Eric's short cut for checking /proc/filesystems and
> bailing immediately in the non-selinux case.  Try this:

There are a couple of other leakage cases to worry about. I submitted
a patch here: http://userspace.selinuxproject.org/trac/ticket/10

--Ed

James Carter | 6 Jan 21:37 2010
Picon

Error building the userspace tools

I don't know what the correct fix for this is, but when I make the
userspace tools with "make LIBDIR=/usr/lib64 SHLIBDIR=/lib64", I need
the patch below for everything to compile.

What I don't know is:
1)  Why is this only required when I am specifying lib64?
2)  Since it is libsemanage that is using libustr and libbz2, why does
semodule and setsebool need to specify them?

This occurs on Fedora 12.  Is the problem due to a difference in the way
Fedora is building the userspace tools?

diff --git a/policycoreutils/semodule/Makefile b/policycoreutils/semodule/Makefile
index c96a286..feba570 100644
--- a/policycoreutils/semodule/Makefile
+++ b/policycoreutils/semodule/Makefile
 <at>  <at>  -7,7 +7,7  <at>  <at>  LIBDIR ?= ${PREFIX}/lib

 CFLAGS ?= -Werror -Wall -W
 override CFLAGS += -I$(INCLUDEDIR)
-LDLIBS = -lsepol -lselinux -lsemanage -L$(LIBDIR)
+LDLIBS = -lustr -lbz2 -lsepol -lselinux -lsemanage -L$(LIBDIR)
 SEMODULE_OBJS = semodule.o

 all: semodule
diff --git a/policycoreutils/setsebool/Makefile b/policycoreutils/setsebool/Makefile
index 556b780..214abc3 100644
--- a/policycoreutils/setsebool/Makefile
+++ b/policycoreutils/setsebool/Makefile
 <at>  <at>  -7,7 +7,7  <at>  <at>  LIBDIR ?= ${PREFIX}/lib
(Continue reading)

Justin P. Mattock | 6 Jan 22:19 2010
Picon

Re: Error building the userspace tools

On 01/06/10 12:37, James Carter wrote:
> I don't know what the correct fix for this is, but when I make the
> userspace tools with "make LIBDIR=/usr/lib64 SHLIBDIR=/lib64", I need
> the patch below for everything to compile.
>
> What I don't know is:
> 1)  Why is this only required when I am specifying lib64?
> 2)  Since it is libsemanage that is using libustr and libbz2, why does
> semodule and setsebool need to specify them?
>
> This occurs on Fedora 12.  Is the problem due to a difference in the way
> Fedora is building the userspace tools?
>
>
>
> diff --git a/policycoreutils/semodule/Makefile b/policycoreutils/semodule/Makefile
> index c96a286..feba570 100644
> --- a/policycoreutils/semodule/Makefile
> +++ b/policycoreutils/semodule/Makefile
>  <at>  <at>  -7,7 +7,7  <at>  <at>  LIBDIR ?= ${PREFIX}/lib
>
>   CFLAGS ?= -Werror -Wall -W
>   override CFLAGS += -I$(INCLUDEDIR)
> -LDLIBS = -lsepol -lselinux -lsemanage -L$(LIBDIR)
> +LDLIBS = -lustr -lbz2 -lsepol -lselinux -lsemanage -L$(LIBDIR)
>   SEMODULE_OBJS = semodule.o
>
>   all: semodule
> diff --git a/policycoreutils/setsebool/Makefile b/policycoreutils/setsebool/Makefile
> index 556b780..214abc3 100644
(Continue reading)

Tomas, Gregg A (IS | 6 Jan 23:34 2010
Picon

Security Context Type Changes

Hi

 

We are currently integrating our SELinux Policy on a RHEL5 machine. However, we are having difficulty in restricting our application within a specific directory because “something” changes our security context type of our users to init_t instead of unconfined_t. Root gets changed to (i.e. <user>:<role>:init_t). We are running with init level 4. We must have tried everything in the book to determine what changes the security context type of our users. Would anyone have any tips?

 

We did change inittab to run init level 5, touch /.autorelabel, rebooted, checked id –Z  and it is unconfined_t. However, ultimately we would like to run with init 4.

 

Thanks in advance.

Stephen Smalley | 7 Jan 15:15 2010
Picon

Re: Security Context Type Changes

On Wed, 2010-01-06 at 16:34 -0600, Tomas, Gregg A (IS) wrote:
> Hi
> 
>  
> 
> We are currently integrating our SELinux Policy on a RHEL5 machine.
> However, we are having difficulty in restricting our application
> within a specific directory because “something” changes our security
> context type of our users to init_t instead of unconfined_t. Root gets
> changed to (i.e. <user>:<role>:init_t). We are running with init level
> 4. We must have tried everything in the book to determine what changes
> the security context type of our users. Would anyone have any tips?
> 
>  
> 
> We did change inittab to run init level 5, touch /.autorelabel,
> rebooted, checked id –Z  and it is unconfined_t. However, ultimately
> we would like to run with init 4.

What is your /etc/inittab configuration for run level 4?

--

-- 
Stephen Smalley
National Security Agency

Hasan Rezaul-CHR010 | 7 Jan 21:37 2010

Help with an SELinux AVC event...

Hi All,

I have a C application task called "sswd" on my Linux system, that opens up the /var/log/audit/audit.log file every 5 seconds, and checks to see if there are any new AVC denies.

I have had this same task doing the same thing for the last few years on a Linux system running selinux. And I have never seen these events in audit.log before complaining about the sswd task... I used to use older selinux packages, and ran the Fedora Core 7 'strict' policy together with some custom policies.

Recently we upgraded our SELinux packages to the very latest (similar to Fedora 12), and we are using Refpolicy as a base policy.

In the /var/log/audit/audit.log file, I see the following event pop up every 5 seconds, and I am guessing its because "sswd" tries to open up the audit.log file every 5 seconds for reading.

1. Can you help me understand what this event is really saying?
2. I have already taken the audit.log file, and used audit2allow to generate any allow rules necessary, but it didnt help to get rid of this particular event.
3. Can I add any specific policy allow lines or transition rules in my custom policy files to get rid of this repeated event ?

Thanks in advance.

The event that pops up every 5 seconds in audit.log is:

type=SYSCALL msg=audit(1262874266.422:260): arch=14 syscall=5 success=yes exit=24 a0=1002b9e4 a1=0 a2=1b6 a3=1b6 items=1 ppid=2463 pid=2794 auid=4294967295 uid=0 gid=601 euid=0 suid=0 fsuid=0 egid=601 sgid=601 fsgid=601 tty=(none) ses=4294967295 comm="sswd" exe="/usr/app/bin/sswd" subj=system_u:system_r:init_t:s0-s15:c0.c255 key="LOG_audit"
type=CWD msg=audit(1262874266.422:260):  cwd="/data"
type=PATH msg=audit(1262874266.422:260): item=0 name="/var/log/audit/audit.log" inode=2061 dev=fd:07 mode=0100600 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:auditd_log_t:s15:c0.c255

root <at> hapWibbSc2:/var/log/audit# ps -eZ | grep sswd
system_u:system_r:init_t:s0-s15:c0.c255 2781 ? 00:00:00 sswd

root <at> hapWibbSc2:/var/log/audit# cd /usr/app/bin
root <at> hapWibbSc2:/usr/app/bin# ls -l sswd
-rwxrwxr-x 1 root root 217204 Jan  1 07:49 sswd

root <at> hapWibbSc2:/usr/app/bin# cd /var/log/audit/
root <at> hapWibbSc2:/var/log/audit#
root <at> hapWibbSc2:/var/log/audit# ls -lZ
-rw-------  root root system_u:object_r:auditd_log_t:s15:c0.c255 audit.log


Gmane