Policies for bastille?

[R. Jensen]

I recently downloaded Bastille and was unable to get
the PSAD portion to install. [Bastille is trying to
install /usr/sbin/psad (among others)].

[root@lankhmar log]# ls -ldZ /usr/sbin
drwxr-xr-x  root     root     system_u:object_r:sbin_t

So I would *expect* an SELinux error if the psad isn't of sbin_t.
[But I don't see any avc messages in the log.]

Here's a portion of Bastille's error log:

{Fri Mar  4 11:15:28 2005} Failed to place /psad as /usr/sbin/psad
{Fri Mar  4 11:15:28 2005} #ERROR: chmod: File /usr/sbin/psad doesn't exist!
{Fri Mar  4 11:15:28 2005} Failed to place /psadwatchd as
/usr/sbin/psadwatchd
{Fri Mar  4 11:15:28 2005} #ERROR: chmod: File /usr/sbin/psadwatchd
doesn't exist!
{Fri Mar  4 11:15:28 2005} Failed to place /kmsgsd as /usr/sbin/kmsgsd
{Fri Mar  4 11:15:28 2005} #ERROR: chmod: File /usr/sbin/kmsgsd doesn't
exist!

Does this look like an SELinux issue or just Bastille?

Richard.

Here is an interesting one

[Richard Irving]

  Recently, I was playing with the hook programs that can be run,
and read via the snmpd daemon....

(like a remote df, or a remote iostat... etc)

The snmpd daemon is given a program to run, if a certain
MIB is strobed...

  This runs fine, when I as root, spawn the SNMPD daemon.

    However, when the automatic boot in rc5.d starts it,
(and it is the identical script file I use to start it with
manually), during init, it appears to work, as the daemon starts....

  but, I get no data back. I -do-, however, find the following
in the logs, however....


   Mar  4 17:00:02 smoker kernel: audit(1109973602.066:0): avc:  denied  { write } for 
pid=1180 
exe=/usr/sbin/snmpd path=pipe:[135310] dev=pipefs ino=135310
scontext=user_u:system_r:snmpd_t 
tcontext=user_u:system_r:snmpd_t tclass=fifo_file

  The source and the targets appear to be the same, yet it is denied.

  ????

    Ideas ?

   init script:

-rwxr-xr-x  root     root     system_u:object_r:initrc_exec_t  /etc/rc.d/init.d/snmpd

An example of a Target file, ran by snmpd:

-r-xr-xr-x  root     root     root:object_r:etc_t              /etc/snmp/snmpload

   It looks as though it cannot properly inherit the childs pipe, when ran by init ?

Here is an interesting one

[Ivan Gyurdiev]

--- snmpd.te    2005-03-05 00:13:17.000000000 -0500
+++ snmpd.new   2005-03-05 00:13:46.000000000 -0500
@@ -45,6 +45,7 @@
 allow snmpd_t proc_t:dir search;
 allow snmpd_t proc_t:file r_file_perms;
 allow snmpd_t self:file { getattr read };
+allow snmpd_t self:fifo_file { read write };

 ifdef(`distro_redhat', `
 ifdef(`rpm.te', `

-- 
Ivan Gyurdiev <ivg2(a)cornell.edu&gt;
Cornell University

Here is an interesting one

[Richard Irving]

Ivan Gyurdiev wrote:
>  --- snmpd.te    2005-03-05 00:13:17.000000000 -0500
>  +++ snmpd.new   2005-03-05 00:13:46.000000000 -0500
>  @@ -45,6 +45,7 @@
>   allow snmpd_t proc_t:dir search;
>   allow snmpd_t proc_t:file r_file_perms;
>   allow snmpd_t self:file { getattr read };
>  +allow snmpd_t self:fifo_file { read write };
>  
>   ifdef(`distro_redhat', `
>   ifdef(`rpm.te', `
>   
   It was the targeted object, not the context.

   Dohh!

   Thanks.

   Next question, on remaking the policy and policy.conf, it turns out the
sources-1.19.15 have a problem. (In a file I haven't touched)

   I can't seem to find a newer rev of the sources,
any idea ?

  1.17 and 1.19.1 are the only two I can find....

Here is an interesting one

[Richard Irving]

Richard Irving wrote:
>  Ivan Gyurdiev wrote:
>  
> > --- snmpd.te    2005-03-05 00:13:17.000000000 -0500
> > +++ snmpd.new   2005-03-05 00:13:46.000000000 -0500
> > @@ -45,6 +45,7 @@ 
<snip>
>   1.17 and 1.19.1 are the only two I can find.... 
   Thank You, Ivan.

   I have synced my sources, added the changes, threw
in a few extras for a few other functions I chained in
on snmpd, as a litmus test...

   And it runs error, and log entry free.

   Once the audit, make, and install, reload.. all works well, this system
is -smooth-. But, I did still have to:

  "dontaudit snmpd_t unconfined_t:process signull;"

To keep from getting one of the scripts to not log.

  I'll chase that down later, as it is the -only- unconfined_t entry
that was involved, and it was a "signull".

   Once again, Thanks.






>  -- 
>  fedora-selinux-list mailing list
>  fedora-selinux-list(a)redhat.com
>  http://www.redhat.com/mailman/listinfo/fedora-selinux-list

Here is an interesting one

[Russell Coker]

On Tuesday 08 March 2005 09:27, Richard Irving <rirving(a)antient.org&gt; wrote:
>    "dontaudit snmpd_t unconfined_t:process signull;" 
Which process is it trying to send signull to?  You will have to either enable 
auditing or use strace or gdb to trace it to discover what is going on.

The access in question may be undesired or it may be something that is 
actually required, without knowing more about your situation it's impossible 
to determine.  It would be best if you could track this down, I don't 
recommend the dontaudit rule without more investigation.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Here is an interesting one

[Russell Coker]

On Saturday 05 March 2005 16:17, Ivan Gyurdiev <ivg2(a)cornell.edu&gt; wrote:
>  --- snmpd.te    2005-03-05 00:13:17.000000000 -0500
>  +++ snmpd.new   2005-03-05 00:13:46.000000000 -0500
>  @@ -45,6 +45,7 @@
>   allow snmpd_t proc_t:dir search;
>   allow snmpd_t proc_t:file r_file_perms;
>   allow snmpd_t self:file { getattr read };
>  +allow snmpd_t self:fifo_file { read write }; 
In a case such as this I suggest using rw_file_perms instead of { read 
write }.  The reason is that restricting access of a domain to itself is of 
little benefit and that once the main access is granted you may as well grant 
the other accesses for the same class.  ioctl access is commonly requested, 
often a child process inherits the file handle and does not know that it's a 
pipe and will perform an ioctl to find out.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

[Jon Savage]

On Fri, 04 Mar 2005 16:23:26 -0600, R. Jensen <linuxuser(a)rhjensen.com&gt; wrote:
>  I recently downloaded Bastille and was unable to get
>  the PSAD portion to install. [Bastille is trying to
>  install /usr/sbin/psad (among others)]. 
<snip>
>  Does this look like an SELinux issue or just Bastille? 
I saw
the same thing and tried installing Bastille on another machine
w/ SELinux disabled
but got the same error. Looks like a Bastille issue IMHO.
-- 
Bests,
Jon