Hasan Rezaul-CHR010 | 1 Dec 01:17 2010

What can selinux do that "audit" by itself cant do ?

Hi All,

Had a thought pop up in my head, and was just cusrious...

Lets say I am using SELinux in my Linux product to monitor the
filesystem and generate avc deny events in audit.log, whenever my strict
selinux policy is violated... And I am running in Permissive mode (so
NOT actively preventing anything, just reporting...).

Is there any reason why I cant simply write a bunch of rules in
audit.rules  to accomplish the same objective ?

Possibly a dumb question, so apologize in advance, but other than Policy
Enforcement and Prevention in the 'Enforcing' mode (which I cant use in
my product for various reasons), what else is SELinux buying me, that I
cant get by using just audit ?

I am sure there must be significant benefits of SELinux, but can someone
help me understand some of the benefits. 

And also perhaps some of the SELinux functionalities are desirable, but
cannot be accomplished by just audit. Can you tell me what those may be?
If there is an article or URL that provides more depth, please feel free
to share that as well.

Thanks as always for your help.

Steve Grubb | 1 Dec 14:44 2010
Picon

Re: What can selinux do that "audit" by itself cant do ?

Hello,

On Tuesday, November 30, 2010 07:17:30 pm Hasan Rezaul-CHR010 wrote:
> Lets say I am using SELinux in my Linux product to monitor the
> filesystem and generate avc deny events in audit.log, whenever my strict
> selinux policy is violated... And I am running in Permissive mode (so
> NOT actively preventing anything, just reporting...).
> 
> Is there any reason why I cant simply write a bunch of rules in
> audit.rules  to accomplish the same objective ?

I think that you want to use the right tool for the right job. The audit system is 
designed to monitor system activity. SE Linux is a MAC subsystem. There are 
requirements that MAC events are auditable, which seems to be what you have been using 
in place of just the audit system.

 It should be known that if you turn SE Linux off, you won't get the same events in the 
audit logs. This is because SE Linux can have policy written that does not like some 
interactions that are "legal" from a DAC perspective. The only way to know if you are 
missing anything important is to run with SE Linux disabled and see if the audit rules 
captures everything you expect.

> Possibly a dumb question, so apologize in advance, but other than Policy
> Enforcement and Prevention in the 'Enforcing' mode (which I cant use in
> my product for various reasons), what else is SELinux buying me, that I
> cant get by using just audit ?

SE Linux has helped debug many software problems like leaked file descriptors or shared 
memory that is executable. The audit system won't be able to catch those since it was 
never designed to concern itself with information flow control. It was designed to 
(Continue reading)

Daniel J Walsh | 1 Dec 15:05 2010
Picon

We have a problem with libselinux leaking memory using __thread


https://bugzilla.redhat.com/show_bug.cgi?id=658571
Hasan Rezaul-CHR010 | 1 Dec 19:06 2010

RE: What can selinux do that "audit" by itself cant do ?

Thank You soo much Steve for your answers  :-)

R.H.

-----Original Message-----
From: Steve Grubb [mailto:sgrubb@...] 
Sent: Wednesday, December 01, 2010 7:45 AM
To: Hasan Rezaul-CHR010
Cc: Stephen Smalley; selinux@...
Subject: Re: What can selinux do that "audit" by itself cant do ?

Hello,

On Tuesday, November 30, 2010 07:17:30 pm Hasan Rezaul-CHR010 wrote:
> Lets say I am using SELinux in my Linux product to monitor the 
> filesystem and generate avc deny events in audit.log, whenever my 
> strict selinux policy is violated... And I am running in Permissive 
> mode (so NOT actively preventing anything, just reporting...).
> 
> Is there any reason why I cant simply write a bunch of rules in 
> audit.rules  to accomplish the same objective ?

I think that you want to use the right tool for the right job. The audit
system is designed to monitor system activity. SE Linux is a MAC
subsystem. There are requirements that MAC events are auditable, which
seems to be what you have been using in place of just the audit system.

 It should be known that if you turn SE Linux off, you won't get the
same events in the audit logs. This is because SE Linux can have policy
written that does not like some interactions that are "legal" from a DAC
(Continue reading)

Eric Paris | 1 Dec 22:22 2010
Picon

[PATCH] SELinux: do not compute transition labels on mountpoint labeled filesystems

selinux_inode_init_security computes transitions sids even for filesystems
that use mount point labeling.  It shouldn't do that.  It should just use
the mount point label always and no matter what.

This causes 2 problems.  1) it makes file creation slower than it needs to be
since we calculate the transition sid and 2) it allows files to be created
with a different label than the mount point!

# id -Z
staff_u:sysadm_r:sysadm_t:s0-s0:c0.c1023
# sesearch --type --class file --source sysadm_t --target tmp_t
Found 1 semantic te rules:
   type_transition sysadm_t tmp_t : file user_tmp_t;

# mount -o loop,context="system_u:object_r:tmp_t:s0"  /tmp/fs /mnt/tmp

# ls -lZ /mnt/tmp
drwx------. root root system_u:object_r:tmp_t:s0       lost+found
# touch /mnt/tmp/file1
# ls -lZ /mnt/tmp
-rw-r--r--. root root staff_u:object_r:user_tmp_t:s0   file1
drwx------. root root system_u:object_r:tmp_t:s0       lost+found

Whoops, we have a mount point labeled filesystem tmp_t with a user_tmp_t
labeled file!

Signed-off-by: Eric Paris <eparis@...>
---

 security/selinux/hooks.c |    5 ++++-
(Continue reading)

James Morris | 1 Dec 23:14 2010

Re: [PATCH] SELinux: do not compute transition labels on mountpoint labeled filesystems

On Wed, 1 Dec 2010, Eric Paris wrote:

> selinux_inode_init_security computes transitions sids even for filesystems
> that use mount point labeling.  It shouldn't do that.  It should just use
> the mount point label always and no matter what.
> 
> This causes 2 problems.  1) it makes file creation slower than it needs to be
> since we calculate the transition sid and 2) it allows files to be created
> with a different label than the mount point!
> 
> # id -Z
> staff_u:sysadm_r:sysadm_t:s0-s0:c0.c1023
> # sesearch --type --class file --source sysadm_t --target tmp_t
> Found 1 semantic te rules:
>    type_transition sysadm_t tmp_t : file user_tmp_t;
> 
> # mount -o loop,context="system_u:object_r:tmp_t:s0"  /tmp/fs /mnt/tmp
> 
> # ls -lZ /mnt/tmp
> drwx------. root root system_u:object_r:tmp_t:s0       lost+found
> # touch /mnt/tmp/file1
> # ls -lZ /mnt/tmp
> -rw-r--r--. root root staff_u:object_r:user_tmp_t:s0   file1
> drwx------. root root system_u:object_r:tmp_t:s0       lost+found
> 
> Whoops, we have a mount point labeled filesystem tmp_t with a user_tmp_t
> labeled file!
>
> Signed-off-by: Eric Paris <eparis@...>
>
(Continue reading)

Eric Blake | 2 Dec 21:59 2010
Picon

Re: libselinux memory leak in multi-threaded processes due to abuse of __thread

On 11/30/2010 04:47 PM, Eric Blake wrote:
> Here's a simple program that demonstrates that libselinux's attempts to
> cache data ends up being a memory leak instead.  The problem is that
> __thread variables have no destructor, so when a long-running program
> that uses multiple pthreads, where each thread uses selinux functions
> which stash malloc'd memory into a __thread cache, then the cache memory
> is leaked when the threads exit.

Eamon's patch[1] looks good to me; and a quick test with my sample
program proves that it avoids the leak.

[1] https://bugzilla.redhat.com/attachment.cgi?id=464338, found at
https://bugzilla.redhat.com/show_bug.cgi?id=658571

--

-- 
Eric Blake   eblake@...    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Eric Paris | 2 Dec 22:06 2010
Picon

[PATCH] selinux: cache sidtab_context_to_sid results

sidtab_context_to_sid takes up a large share of time when creating large
numbers of new inodes (~30-40% in oprofile runs).  This patch implements a
cache of 3 entries which is checked before we do a full context_to_sid lookup.
On one system this showed over a x3 improvement in the number of inodes that
could be created per second and around a 20% improvement on another system.

Any time we look up the same context string sucessivly (imagine ls -lZ) we
should hit this cache hot.  A cache miss should have a relatively minor affect
on performance next to doing the full table search.

All operations on the cache are done COMPLETELY lockless.  We know that all
struct sidtab_node objects created will never be deleted until a new policy is
loaded thus we never have to worry about a pointer being dereferenced.  Since
we also know that pointer assignment is atomic we know that the cache will
always have valid pointers.  Given this information we implement a FIFO cache
in an array of 3 pointers.  Every result (whether a cache hit or table lookup)
will be places in the 0 spot of the cache and the rest of the entries moved
down one spot.  The 3rd entry will be lost.

Races are possible and are even likely to happen.  Lets assume that 4 tasks
are hitting sidtab_context_to_sid.  The first task checks against the first
entry in the cache and it is a miss.  Now lets assume a second task updates
the cache with a new entry.  This will push the first entry back to the second
spot.  Now the first task might check against the second entry (which it
already checked) and will miss again.  Now say some third task updates the
cache and push the second entry to the third spot.  The first task my check
the third entry (for the third time!) and again have a miss.  At which point
it will just do a full table lookup.  No big deal!

Signed-off-by: Eric Paris <eparis@...>
(Continue reading)

Eamon Walsh | 3 Dec 02:02 2010
Picon

Re: libselinux memory leak in multi-threaded processes due to abuse of __thread

On 12/02/2010 03:59 PM, Eric Blake wrote:
> On 11/30/2010 04:47 PM, Eric Blake wrote:
>> Here's a simple program that demonstrates that libselinux's attempts to
>> cache data ends up being a memory leak instead.  The problem is that
>> __thread variables have no destructor, so when a long-running program
>> that uses multiple pthreads, where each thread uses selinux functions
>> which stash malloc'd memory into a __thread cache, then the cache memory
>> is leaked when the threads exit.
> Eamon's patch[1] looks good to me; and a quick test with my sample
> program proves that it avoids the leak.
>
> [1] https://bugzilla.redhat.com/attachment.cgi?id=464338, found at
> https://bugzilla.redhat.com/show_bug.cgi?id=658571
>

Pushed to libselinux 2.0.97.

--

-- 

Eamon Walsh 
National Security Agency

Eric Paris | 3 Dec 22:45 2010
Picon

[RFC PATCH 1/2] fs/vfs/security: pass last path component to LSM on inode creation

SELinux would like to implement a new labeling behavior of newly created
inodes.  We currently label new inodes based on the parent and the creating
process.  This new behavior would also take into account the name of the
new object when deciding the new label.  This is not the (supposed) full path,
just the last component of the path.

This is very useful because creating /etc/shadow is different than creating
/etc/passwd but the kernel hooks are unable to differentiate these
operations.  We currently require that userspace realize it is doing some
difficult operation like that and that userspace jump through SELinux hoops
to get things set up correctly.  This patch does not implement new
behavior, that is obviously contained in a seperate SELinux patch, but it
does pass the needed name down to the correct LSM hook.  If no such name
exists it is fine to pass NULL.

Signed-off-by: Eric Paris <eparis <at> redhat.com>
---

 fs/btrfs/inode.c               |   11 ++++++-----
 fs/btrfs/xattr.c               |    3 ++-
 fs/btrfs/xattr.h               |    1 +
 fs/ext2/ext2.h                 |    2 +-
 fs/ext2/ialloc.c               |    4 ++--
 fs/ext2/namei.c                |    8 ++++----
 fs/ext2/xattr.h                |    4 ++--
 fs/ext2/xattr_security.c       |    4 ++--
 fs/ext3/ialloc.c               |    5 +++--
 fs/ext3/namei.c                |    8 ++++----
 fs/ext3/xattr.h                |    8 ++++----
 fs/ext3/xattr_security.c       |    5 +++--
(Continue reading)


Gmane