headers
Hasan Rezaul-CHR010 | 1 Dec 2010 01:17

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.
Permalink | Reply | 2 comments |
headers
Steve Grubb | 1 Dec 2010 14:44
Picon
Favicon

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)

Permalink | Reply | 1 comment |
headers
Daniel J Walsh | 1 Dec 2010 15:05
Picon
Favicon
Gravatar

We have a problem with libselinux leaking memory using __thread


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

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)

Permalink | Reply | 0 comments |
headers
Eric Paris | 1 Dec 2010 22:22
Picon
Favicon

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

Permalink | Reply | 1 comment |
headers
James Morris | 1 Dec 2010 23:14
Favicon

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)

Permalink | Reply | 0 comments |
headers
Eric Blake | 2 Dec 2010 21:59
Picon
Favicon
Gravatar

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
Permalink | Reply | 1 comment |
headers
Eric Paris | 2 Dec 2010 22:06
Picon
Favicon

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

Permalink | Reply | 3 comments |
headers
Eamon Walsh | 3 Dec 2010 02:02
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
Permalink | Reply | 0 comments |
headers
Casey Schaufler | 5 Dec 2010 08:38

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

On 12/4/2010 1:34 PM, Eric Paris wrote:
> On Fri, 2010-12-03 at 20:20 -0800, Casey Schaufler wrote:
>> On 12/3/2010 1:45 PM, Eric Paris wrote:
>>> 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.
>> I see. Pathname based controls. In SELinux.
> Actually you of (almost) all people shouldn't make this mistake.

Sorry Eric, but if it looks like a duck, quacks like a duck, and
bites like a duck it's a good bet that what you have is a duck.
Better get out the Grand Mariner and start on a sauce.

> There
> is absolutely no pathname based controls being implemented.  This is an
> extension of the object labeling model to facilitate and simply some
> userspace issues related to the labeling of NEW objects.  

The end to which the controls are put does not change the character
of those controls. If the attribute of the file being used is the
name component of the name/inode pair in a directory entry than what
you have is a pathname based control mechanism. It will have all of
the downsides, including mount points and hard links, that any other
name based scheme will suffer from.

> SELinux very
> much so is and will continue to be based solely on label based controls.
(Continue reading)

Permalink | Reply | 11 comments |

Gmane