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 

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(-)
> 

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

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

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

Security Context Type Changes

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

Help with an SELinux AVC event...

Re: Help with an SELinux AVC event...

On Thu, 2010-01-07 at 15:37 -0500, Hasan Rezaul-CHR010 wrote:
> 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

That's your audit configuration (/etc/audit/audit.rules), not SELinux.
You have an audit rule that says to log all access to the audit log
file, presumably copied from the sample audit rules for the CAPP or LSPP
configurations.  Looks like this in audit.rules:
-w /var/log/audit/ -k LOG_audit

I think you'd be better off using audispd to dispatch audit events to
your program rather than directly reading audit.log yourself.
> 
> 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
> 
> 
> 
--

-- 
Stephen Smalley
National Security Agency

Re: Help with an SELinux AVC event...

On 01/07/2010 03:43 PM, Stephen Smalley wrote:
> On Thu, 2010-01-07 at 15:37 -0500, Hasan Rezaul-CHR010 wrote:
>> 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
> 
> That's your audit configuration (/etc/audit/audit.rules), not SELinux.
> You have an audit rule that says to log all access to the audit log
> file, presumably copied from the sample audit rules for the CAPP or LSPP
> configurations.  Looks like this in audit.rules:
> -w /var/log/audit/ -k LOG_audit
> 
> I think you'd be better off using audispd to dispatch audit events to
> your program rather than directly reading audit.log yourself.
>>
>> 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
>>
>>
>>
You probably want to steal the code in sedisp in the setroubleshoot package, since this is exactly what it does.