Selinux error help - continued

[Dan Track]

On Wed, 2007-02-07 at 16:34 +0000, Dan Track wrote:
>  Hi Stephen
>
>  Firstly apologies for sending to the wrong list. 
Ok, then take follow-ups to fedora-selinux-list please.

>  Thanks for the advice it was really an eye opener. I trawlled
> through
>  the assert.te file in my selinux src directory, however I can tell
>  which rule to remove, could you please guide to which rule it is.
>  Currently my file looks like this:
>
>  neverallow { domain -unrestricted -snmpd_t -pegasus_t }
>  unconfined_t:process ~sigchld; 
The rule above.  Rather than removing it entirely, you could adjust it
to make a specific exception for this case.  What do you truly need your
process to be able to do?

>  # Confined domains must never see unconfined domain's /proc/pid
> entries.
>  neverallow { domain -unrestricted -snmpd_t -pegasus_t }
>  unconfined_t:dir { getattr search }; 
This one will also get in your process' way if it truly needs to operate
on unconfined processes.

Naturally, if you go too far in this direction, you are effectively
removing any real restriction on httpd and might as well just disable
its protection altogether (via the corresponding boolean).

Hi Stephen.

I've moved the conversation over to the selinux list. My program is
actually Beltane which is a web front end for managing samhain ( a
filesystem integrity checker). The point at which the problem arises
is when a setuid binary (belatne_cp) wants to write to a file it
creates in the /tmp directory and then it wants to move that file to
the /var/lib/yule/profiles directory. Its at this point I get the
selinux error:

Feb  7 14:26:10 jupiter kernel: audit(1170858370.177:2547): avc:
denied  { getsession } for  pid=555 comm="httpd"
scontext=root:system_r:httpd_t tcontext=root:system_r:unconfined_t
tclass=process
Feb  7 14:26:27 jupiter kernel: audit(1170858387.985:2548): avc:
denied  { getattr } for  pid=14295 comm="beltane_cp"
name="TMPFILIyEqoa" dev=sda3 ino=147699
scontext=root:system_r:httpd_sys_script_t
tcontext=root:object_r:httpd_var_lib_t tclass=file

This beltane_cp file is called by apache.

Hope this helps in making clear what I'm trying to do.

Thanks again
Dan

[Stephen Smalley]

On Wed, 2007-02-07 at 17:08 +0000, Dan Track wrote:
>  Hi Stephen.
>  
>  I've moved the conversation over to the selinux list. My program is
>  actually Beltane which is a web front end for managing samhain ( a
>  filesystem integrity checker). The point at which the problem arises
>  is when a setuid binary (belatne_cp) wants to write to a file it
>  creates in the /tmp directory and then it wants to move that file to
>  the /var/lib/yule/profiles directory. 
Sounds like you should have a separate domain for that binary, and a
separate type on that directory, so that you can give it the right
permissions without affecting anything else.

>   Its at this point I get the
>  selinux error:
>  
>  Feb  7 14:26:10 jupiter kernel: audit(1170858370.177:2547): avc:
>  denied  { getsession } for  pid=555 comm="httpd"
>  scontext=root:system_r:httpd_t tcontext=root:system_r:unconfined_t
>  tclass=process 
Question is what process is the target of this getsid(2) call?
You can find out more information by enabling system call auditing and
retrying.  auditctl -e 1 or boot with audit=1 or run auditd.

-- 
Stephen Smalley
National Security Agency

[Dan Track]

On 2/7/07, Stephen Smalley <sds(a)tycho.nsa.gov&gt; wrote:
>  On Wed, 2007-02-07 at 17:08 +0000, Dan Track wrote:
>  > Hi Stephen.
>  >
>  > I've moved the conversation over to the selinux list. My program is
>  > actually Beltane which is a web front end for managing samhain ( a
>  > filesystem integrity checker). The point at which the problem arises
>  > is when a setuid binary (belatne_cp) wants to write to a file it
>  > creates in the /tmp directory and then it wants to move that file to
>  > the /var/lib/yule/profiles directory.
>
>  Sounds like you should have a separate domain for that binary, and a
>  separate type on that directory, so that you can give it the right
>  permissions without affecting anything else.
>
>  >  Its at this point I get the
>  > selinux error:
>  >
>  > Feb  7 14:26:10 jupiter kernel: audit(1170858370.177:2547): avc:
>  > denied  { getsession } for  pid=555 comm="httpd"
>  > scontext=root:system_r:httpd_t tcontext=root:system_r:unconfined_t
>  > tclass=process
>
>  Question is what process is the target of this getsid(2) call?
>  You can find out more information by enabling system call auditing and
>  retrying.  auditctl -e 1 or boot with audit=1 or run auditd.
>
>  --
>  Stephen Smalley
>  National Security Agency
>
>  

On 2/7/07, Stephen Smalley <sds(a)tycho.nsa.gov&gt; wrote:
>  On Wed, 2007-02-07 at 17:08 +0000, Dan Track wrote:
>  > Hi Stephen.
>  >
>  > I've moved the conversation over to the selinux list. My program is
>  > actually Beltane which is a web front end for managing samhain ( a
>  > filesystem integrity checker). The point at which the problem arises
>  > is when a setuid binary (belatne_cp) wants to write to a file it
>  > creates in the /tmp directory and then it wants to move that file to
>  > the /var/lib/yule/profiles directory.
>
>  Sounds like you should have a separate domain for that binary, and a
>  separate type on that directory, so that you can give it the right
>  permissions without affecting anything else.
>
>  >  Its at this point I get the
>  > selinux error:
>  >
>  > Feb  7 14:26:10 jupiter kernel: audit(1170858370.177:2547): avc:
>  > denied  { getsession } for  pid=555 comm="httpd"
>  > scontext=root:system_r:httpd_t tcontext=root:system_r:unconfined_t
>  > tclass=process
>
>  Question is what process is the target of this getsid(2) call?
>  You can find out more information by enabling system call auditing and
>  retrying.  auditctl -e 1 or boot with audit=1 or run auditd. 

Hi Stephen

Hope things are good.

I enabled the auditctl and got the following in /var/log/messages

Feb  8 10:26:51 jupiter kernel: audit(1170930411.956:2939): avc:
denied  { getattr } for  pid=6992 comm="beltane_cp"
name="TMPFILuB4KTI" dev=sda3 ino=147701
scontext=root:system_r:httpd_sys_script_t
tcontext=root:object_r:httpd_var_lib_t tclass=file
Feb  8 10:26:51 jupiter kernel: audit(1170930411.956:2939):
arch=40000003 syscall=196 success=no exit=-13 a0=bff6ab9d a1=bfed575c
a2=8a9ff4 a3=bfed575c items=1 pid=6992 auid=4294967295 uid=48 gid=48
euid=0 suid=0 fsuid=0 egid=48 sgid=48 fsgid=48 comm="beltane_cp"
exe="/usr/local/bin/beltane_cp"
Feb  8 10:26:51 jupiter kernel: audit(1170930411.956:2939):
path="/var/lib/yule/profiles/TMPFILuB4KTI"
Feb  8 10:26:51 jupiter kernel: audit(1170930411.956:2939):
cwd="/opt/www/beltane/php"
Feb  8 10:26:51 jupiter kernel: audit(1170930411.956:2939):
name="/var/lib/yule/profiles/TMPFILuB4KTI" flags=0
Feb  8 10:26:51 jupiter kernel:  inode=147701 dev=08:03 mode=0100600
ouid=48 ogid=48 rdev=00:00

Hope this helps to figure out what is going on.

Many Thanks
Dan

[Stephen Smalley]

On Thu, 2007-02-08 at 10:35 +0000, Dan Track wrote:
>  I enabled the auditctl and got the following in /var/log/messages
>  
>  Feb  8 10:26:51 jupiter kernel: audit(1170930411.956:2939): avc:
>  denied  { getattr } for  pid=6992 comm="beltane_cp"
>  name="TMPFILuB4KTI" dev=sda3 ino=147701
>  scontext=root:system_r:httpd_sys_script_t
>  tcontext=root:object_r:httpd_var_lib_t tclass=file
>  Feb  8 10:26:51 jupiter kernel: audit(1170930411.956:2939):
>  arch=40000003 syscall=196 success=no exit=-13 a0=bff6ab9d a1=bfed575c
>  a2=8a9ff4 a3=bfed575c items=1 pid=6992 auid=4294967295 uid=48 gid=48
>  euid=0 suid=0 fsuid=0 egid=48 sgid=48 fsgid=48 comm="beltane_cp"
>  exe="/usr/local/bin/beltane_cp"
>  Feb  8 10:26:51 jupiter kernel: audit(1170930411.956:2939):
>  path="/var/lib/yule/profiles/TMPFILuB4KTI"
>  Feb  8 10:26:51 jupiter kernel: audit(1170930411.956:2939):
>  cwd="/opt/www/beltane/php"
>  Feb  8 10:26:51 jupiter kernel: audit(1170930411.956:2939):
>  name="/var/lib/yule/profiles/TMPFILuB4KTI" flags=0
>  Feb  8 10:26:51 jupiter kernel:  inode=147701 dev=08:03 mode=0100600
>  ouid=48 ogid=48 rdev=00:00
>  
>  Hope this helps to figure out what is going on. 
That shows the full path information for the access
to /var/lib/yule/profiles.  Just need to select an appropriate type for
that directory that allows your script to write to it as is, like
httpd_sys_script_rw_t, and apply it to those files.   In FC4 or earlier,
that would be something like:
	chcon -R -t httpd_sys_script_rw_t /var/lib/yule/profiles

But I was hoping to also see the audit information for the other denial
(the getsession one) - can you reproduce it with audit enabled?  And
then when you get the output, take the first argument (a0) and check to
see what process it corresponds to.

-- 
Stephen Smalley
National Security Agency

[Dan Track]

On 2/8/07, Stephen Smalley <sds(a)tycho.nsa.gov&gt; wrote:
>  On Thu, 2007-02-08 at 10:35 +0000, Dan Track wrote:
>  > I enabled the auditctl and got the following in /var/log/messages
>  >
>  > Feb  8 10:26:51 jupiter kernel: audit(1170930411.956:2939): avc:
>  > denied  { getattr } for  pid=6992 comm="beltane_cp"
>  > name="TMPFILuB4KTI" dev=sda3 ino=147701
>  > scontext=root:system_r:httpd_sys_script_t
>  > tcontext=root:object_r:httpd_var_lib_t tclass=file
>  > Feb  8 10:26:51 jupiter kernel: audit(1170930411.956:2939):
>  > arch=40000003 syscall=196 success=no exit=-13 a0=bff6ab9d a1=bfed575c
>  > a2=8a9ff4 a3=bfed575c items=1 pid=6992 auid=4294967295 uid=48 gid=48
>  > euid=0 suid=0 fsuid=0 egid=48 sgid=48 fsgid=48 comm="beltane_cp"
>  > exe="/usr/local/bin/beltane_cp"
>  > Feb  8 10:26:51 jupiter kernel: audit(1170930411.956:2939):
>  > path="/var/lib/yule/profiles/TMPFILuB4KTI"
>  > Feb  8 10:26:51 jupiter kernel: audit(1170930411.956:2939):
>  > cwd="/opt/www/beltane/php"
>  > Feb  8 10:26:51 jupiter kernel: audit(1170930411.956:2939):
>  > name="/var/lib/yule/profiles/TMPFILuB4KTI" flags=0
>  > Feb  8 10:26:51 jupiter kernel:  inode=147701 dev=08:03 mode=0100600
>  > ouid=48 ogid=48 rdev=00:00
>  >
>  > Hope this helps to figure out what is going on.
>
>  That shows the full path information for the access
>  to /var/lib/yule/profiles.  Just need to select an appropriate type for
>  that directory that allows your script to write to it as is, like
>  httpd_sys_script_rw_t, and apply it to those files.   In FC4 or earlier,
>  that would be something like:
>          chcon -R -t httpd_sys_script_rw_t /var/lib/yule/profiles
>
>  But I was hoping to also see the audit information for the other denial
>  (the getsession one) - can you reproduce it with audit enabled?  And
>  then when you get the output, take the first argument (a0) and check to
>  see what process it corresponds to.
>
>  --
>  Stephen Smalley
>  National Security Agency
>
>  
Hi
Thanks for getting back.
I started the audit daemon and I got the following come up when I
tried to create a profile from the web page:
ype=AVC msg=audit(1170945767.596:8934): avc:  denied  { getattr } for
pid=18356 comm="beltane_cp" name="TMPFILvLYQ7Z" dev=sda3 ino=147703
scontext=root:system_r:httpd_sys_script_t
tcontext=root:object_r:httpd_var_lib_t tclass=file
type=SYSCALL msg=audit(1170945767.596:8934): arch=40000003 syscall=196
success=no exit=-13 a0=bffa1b9d a1=bff42cdc a2=8a9ff4 a3=bff42cdc
items=1 pid=18356 auid=4294967295 uid=48 gid=48 euid=0 suid=0 fsuid=0
egid=48 sgid=48 fsgid=48 comm="beltane_cp"
exe="/usr/local/bin/beltane_cp"
type=AVC_PATH msg=audit(1170945767.596:8934):
path="/var/lib/yule/profiles/TMPFILvLYQ7Z"
type=CWD msg=audit(1170945767.596:8934):  cwd="/opt/www/beltane/php"
type=PATH msg=audit(1170945767.596:8934):
name="/var/lib/yule/profiles/TMPFILvLYQ7Z" flags=0  inode=147703
dev=08:03 mode=0100600 ouid=48 ogid=48 rdev=00:00
type=AVC msg=audit(1170945774.915:8935): avc:  denied  { getsession }
for  pid=15500 comm="httpd" scontext=root:system_r:httpd_t
tcontext=root:system_r:unconfined_t tclass=process
type=AVC msg=audit(1170945805.142:8936): avc:  denied  { getsession }
for  pid=31207 comm="httpd" scontext=root:system_r:httpd_t
tcontext=root:system_r:unconfined_t tclass=process
type=AVC msg=audit(1170945835.202:8937): avc:  denied  { getsession }
for  pid=15498 comm="httpd" scontext=root:system_r:httpd_t
tcontext=root:system_r:unconfined_t tclass=process

I'm not sure what you meant by the "a0" argument. The exe in the above
output shows "/usr/local/bin/beltane_cp" and the uid show 48 (apache).
Is this what you meant?

Thanks
Dan

[Stephen Smalley]

On Thu, 2007-02-08 at 14:48 +0000, Dan Track wrote:
>  Thanks for getting back.
>  I started the audit daemon and I got the following come up when I
>  tried to create a profile from the web page:
>  ype=AVC msg=audit(1170945767.596:8934): avc:  denied  { getattr } for
>  pid=18356 comm="beltane_cp" name="TMPFILvLYQ7Z" dev=sda3 ino=147703
>  scontext=root:system_r:httpd_sys_script_t
>  tcontext=root:object_r:httpd_var_lib_t tclass=file
>  type=SYSCALL msg=audit(1170945767.596:8934): arch=40000003 syscall=196
>  success=no exit=-13 a0=bffa1b9d a1=bff42cdc a2=8a9ff4 a3=bff42cdc
>  items=1 pid=18356 auid=4294967295 uid=48 gid=48 euid=0 suid=0 fsuid=0
>  egid=48 sgid=48 fsgid=48 comm="beltane_cp"
>  exe="/usr/local/bin/beltane_cp"
>  type=AVC_PATH msg=audit(1170945767.596:8934):
>  path="/var/lib/yule/profiles/TMPFILvLYQ7Z"
>  type=CWD msg=audit(1170945767.596:8934):  cwd="/opt/www/beltane/php"
>  type=PATH msg=audit(1170945767.596:8934):
>  name="/var/lib/yule/profiles/TMPFILvLYQ7Z" flags=0  inode=147703
>  dev=08:03 mode=0100600 ouid=48 ogid=48 rdev=00:00
>  type=AVC msg=audit(1170945774.915:8935): avc:  denied  { getsession }
>  for  pid=15500 comm="httpd" scontext=root:system_r:httpd_t
>  tcontext=root:system_r:unconfined_t tclass=process
>  type=AVC msg=audit(1170945805.142:8936): avc:  denied  { getsession }
>  for  pid=31207 comm="httpd" scontext=root:system_r:httpd_t
>  tcontext=root:system_r:unconfined_t tclass=process
>  type=AVC msg=audit(1170945835.202:8937): avc:  denied  { getsession }
>  for  pid=15498 comm="httpd" scontext=root:system_r:httpd_t
>  tcontext=root:system_r:unconfined_t tclass=process
>  
>  I'm not sure what you meant by the "a0" argument. The exe in the above
>  output shows "/usr/local/bin/beltane_cp" and the uid show 48 (apache).
>  Is this what you meant? 
I'm looking for the SYSCALL record that corresponds to the getsession
AVC message.  It should have the same audit event id as the AVC message.
But I don't see one above.  What I was interested in was what pid is
being passed to the getsid() call, and what process corresponds to that
pid - that is the unconfined process that httpd is trying to get
information about.

-- 
Stephen Smalley
National Security Agency

[Dan Track]

On 2/8/07, Stephen Smalley <sds(a)tycho.nsa.gov&gt; wrote:
>  On Thu, 2007-02-08 at 14:48 +0000, Dan Track wrote:
>  > Thanks for getting back.
>  > I started the audit daemon and I got the following come up when I
>  > tried to create a profile from the web page:
>  > ype=AVC msg=audit(1170945767.596:8934): avc:  denied  { getattr } for
>  > pid=18356 comm="beltane_cp" name="TMPFILvLYQ7Z" dev=sda3
> ino=147703
>  > scontext=root:system_r:httpd_sys_script_t
>  > tcontext=root:object_r:httpd_var_lib_t tclass=file
>  > type=SYSCALL msg=audit(1170945767.596:8934): arch=40000003 syscall=196
>  > success=no exit=-13 a0=bffa1b9d a1=bff42cdc a2=8a9ff4 a3=bff42cdc
>  > items=1 pid=18356 auid=4294967295 uid=48 gid=48 euid=0 suid=0 fsuid=0
>  > egid=48 sgid=48 fsgid=48 comm="beltane_cp"
>  > exe="/usr/local/bin/beltane_cp"
>  > type=AVC_PATH msg=audit(1170945767.596:8934):
>  > path="/var/lib/yule/profiles/TMPFILvLYQ7Z"
>  > type=CWD msg=audit(1170945767.596:8934):  cwd="/opt/www/beltane/php"
>  > type=PATH msg=audit(1170945767.596:8934):
>  > name="/var/lib/yule/profiles/TMPFILvLYQ7Z" flags=0  inode=147703
>  > dev=08:03 mode=0100600 ouid=48 ogid=48 rdev=00:00
>  > type=AVC msg=audit(1170945774.915:8935): avc:  denied  { getsession }
>  > for  pid=15500 comm="httpd" scontext=root:system_r:httpd_t
>  > tcontext=root:system_r:unconfined_t tclass=process
>  > type=AVC msg=audit(1170945805.142:8936): avc:  denied  { getsession }
>  > for  pid=31207 comm="httpd" scontext=root:system_r:httpd_t
>  > tcontext=root:system_r:unconfined_t tclass=process
>  > type=AVC msg=audit(1170945835.202:8937): avc:  denied  { getsession }
>  > for  pid=15498 comm="httpd" scontext=root:system_r:httpd_t
>  > tcontext=root:system_r:unconfined_t tclass=process
>  >
>  > I'm not sure what you meant by the "a0" argument. The exe in the
> above
>  > output shows "/usr/local/bin/beltane_cp" and the uid show 48 (apache).
>  > Is this what you meant?
>
>  I'm looking for the SYSCALL record that corresponds to the getsession
>  AVC message.  It should have the same audit event id as the AVC message.
>  But I don't see one above.  What I was interested in was what pid is
>  being passed to the getsid() call, and what process corresponds to that
>  pid - that is the unconfined process that httpd is trying to get
>  information about.
>  
Hi

I've tried to capture the process information that is triggiring these
alerts but so far I'm failing. Basically the web page is just a form
which you submit as soon as you press the submit button the whole
process is over in a second.

I've tried running the following to capture what is causing it:
 tail -f /var/log/audit/audit.log| grep SYSCALL  | grep beltane | awk
-F' ' {'print $12'} | awk -F'=' {'print
"/proc/"$2"/cmdline"'} | xargs
cat $1

But I'm getting blanks when running with tail. Any ideas of another
way to capture the info using the pid in the a0 line of the audit log.

Thanks in advance
Dan

[Stephen Smalley]

On Thu, 2007-02-08 at 16:09 +0000, Dan Track wrote:
>  I've tried to capture the process information that is triggiring
> these
>  alerts but so far I'm failing. Basically the web page is just a form
>  which you submit as soon as you press the submit button the whole
>  process is over in a second. 
Well, you could just wrap the script under strace or autrace or
something similar.

Question:  What happens if you don't allow the getsession permission but
just fix up the file permissions by running chcon as I suggested?  Does
the getsession denial actually prevent it from working?

-- 
Stephen Smalley
National Security Agency

[Dan Track]

On 2/8/07, Stephen Smalley <sds(a)tycho.nsa.gov&gt; wrote:
>  On Thu, 2007-02-08 at 16:09 +0000, Dan Track wrote:
>  > I've tried to capture the process information that is triggiring these
>  > alerts but so far I'm failing. Basically the web page is just a form
>  > which you submit as soon as you press the submit button the whole
>  > process is over in a second.
>
>  Well, you could just wrap the script under strace or autrace or
>  something similar.
>
>  Question:  What happens if you don't allow the getsession permission but
>  just fix up the file permissions by running chcon as I suggested?  Does
>  the getsession denial actually prevent it from working?
>
>  -- 
Hi

I just ran the chcon command you gave and now the web page script
works fine. So it seems to have fixed the problem. But I'm still
intrigued by your investigation, and I'd like to continue it.

Since this is a httpd process how would I run strace on any child
process that may appear?

Thanks in advance
Dan

[Stephen Smalley]

On Thu, 2007-02-08 at 16:31 +0000, Dan Track wrote:
>  On 2/8/07, Stephen Smalley <sds(a)tycho.nsa.gov&gt; wrote:
>  > On Thu, 2007-02-08 at 16:09 +0000, Dan Track wrote:
>  > > I've tried to capture the process information that is triggiring these
>  > > alerts but so far I'm failing. Basically the web page is just a form
>  > > which you submit as soon as you press the submit button the whole
>  > > process is over in a second.
>  >
>  > Well, you could just wrap the script under strace or autrace or
>  > something similar.
>  >
>  > Question:  What happens if you don't allow the getsession permission but
>  > just fix up the file permissions by running chcon as I suggested?  Does
>  > the getsession denial actually prevent it from working?
>  >
>  > --
>  
>  Hi
>  
>  I just ran the chcon command you gave and now the web page script
>  works fine. So it seems to have fixed the problem. But I'm still
>  intrigued by your investigation, and I'd like to continue it.
>  
>  Since this is a httpd process how would I run strace on any child
>  process that may appear? 
You could wrap your current script with a script that invokes it with
strace -f -ff -o /tmp/webtrace <nameofrealscript>. Or, at a cost of
tracing the entire apache process and all descendants, you could do:
# /etc/init.d/httpd stop
# strace -f -ff -o webtrace /usr/sbin/httpd

Then you should see a webtrace.<pid> file for each process created by
httpd with the trace information.  In which you can grep for a call to
getsid and see the pid that was passed to it (and possibly how it was
obtained in the first place, from the preceding calls).

-- 
Stephen Smalley
National Security Agency

[Dan Track]

On 2/8/07, Stephen Smalley <sds(a)tycho.nsa.gov&gt; wrote:
>  On Thu, 2007-02-08 at 16:31 +0000, Dan Track wrote:
>  > On 2/8/07, Stephen Smalley <sds(a)tycho.nsa.gov&gt; wrote:
>  > > On Thu, 2007-02-08 at 16:09 +0000, Dan Track wrote:
>  > > > I've tried to capture the process information that is triggiring
> these
>  > > > alerts but so far I'm failing. Basically the web page is just a form
>  > > > which you submit as soon as you press the submit button the whole
>  > > > process is over in a second.
>  > >
>  > > Well, you could just wrap the script under strace or autrace or
>  > > something similar.
>  > >
>  > > Question:  What happens if you don't allow the getsession permission but
>  > > just fix up the file permissions by running chcon as I suggested?  Does
>  > > the getsession denial actually prevent it from working?
>  > >
>  > > --
>  >
>  > Hi
>  >
>  > I just ran the chcon command you gave and now the web page script
>  > works fine. So it seems to have fixed the problem. But I'm still
>  > intrigued by your investigation, and I'd like to continue it.
>  >
>  > Since this is a httpd process how would I run strace on any child
>  > process that may appear?
>
>  You could wrap your current script with a script that invokes it with
>  strace -f -ff -o /tmp/webtrace <nameofrealscript>. Or, at a cost of
>  tracing the entire apache process and all descendants, you could do:
>  # /etc/init.d/httpd stop
>  # strace -f -ff -o webtrace /usr/sbin/httpd
>
>  Then you should see a webtrace.<pid> file for each process created by
>  httpd with the trace information.  In which you can grep for a call to
>  getsid and see the pid that was passed to it (and possibly how it was
>  obtained in the first place, from the preceding calls).
>  
Hi

Ok I just ran your strace and I got two files that contain the getsid
call. Not sure how to read where the pid is so I'll past a portion of
the file incase you can read it better than me.

The other strange thing is that I'm not getting any more selinux
notifications (SYSCALL) since issuing your chcon command. There are no
httpd violations. Should I back out the chcon to get the errors back?

webtrace.25428
lstat64("/opt/www/.beltanerc", {st_mode=S_IFREG|0600, st_size=751, ...}) = 0
open("/opt/www/.beltanerc", O_RDONLY) = 14
fstat64(14, {st_mode=S_IFREG|0600, st_size=751, ...}) = 0
lseek(14, 0, SEEK_CUR)                  = 0
lseek(14, 0, SEEK_SET)                  = 0
fstat64(14, {st_mode=S_IFREG|0600, st_size=751, ...}) = 0
mmap2(NULL, 751, PROT_READ, MAP_SHARED, 14, 0) = 0xb7bc1000
munmap(0xb7bc1000, 751)                           = 0
close(14)                           = 0
time(NULL) = 1170954121
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1323, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1323, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1323, ...}) = 0
access("/var/run/yule.pid", F_OK)       = 0
getcwd("/opt/www/beltane/php", 4096)    = 21
lstat64("/var", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("/var/run", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("/var/run/yule.pid", {st_mode=S_IFREG|0644, st_size=6, ...}) = 0
open("/var/run/yule.pid", O_RDONLY)     = 14
fstat64(14, {st_mode=S_IFREG|0644, st_size=6, ...}) = 0
lseek(14, 0, SEEK_CUR) = 0
lseek(14, 0, SEEK_SET)                  = 0
fstat64(14, {st_mode=S_IFREG|0644, st_size=6, ...}) = 0
mmap2(NULL, 6, PROT_READ, MAP_SHARED, 14, 0) = 0xb7bc1000
munmap(0xb7bc1000, 6)                   = 0
close(14)                               = 0
getsid(26060)                           = 26059
munmap(0xb7b85000, 86016)               = 0
chdir("/")                              = 0
umask(022)                              = 022
pwrite64(13, "count|i:196;timestamp|i:11709541"..., 122, 0) = 122
close(13) = 0


webtrace.25429
lstat64("/opt/www/.beltanerc", {st_mode=S_IFREG|0600, st_size=751, ...}) = 0
open("/opt/www/.beltanerc", O_RDONLY)   = 14
fstat64(14, {st_mode=S_IFREG|0600, st_size=751, ...}) = 0
lseek(14, 0, SEEK_CUR)                  = 0
lseek(14, 0, SEEK_SET)                  = 0
fstat64(14, {st_mode=S_IFREG|0600, st_size=751, ...}) = 0
mmap2(NULL, 751, PROT_READ, MAP_SHARED, 14, 0) = 0xb7bc1000
munmap(0xb7bc1000, 751)                 = 0
close(14)                               = 0
time(NULL)                              = 1170954151
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1323, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1323, ...}) = 0
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1323, ...}) = 0
access("/var/run/yule.pid", F_OK)       = 0
getcwd("/opt/www/beltane/php", 4096)    = 21
lstat64("/var", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("/var/run", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("/var/run/yule.pid", {st_mode=S_IFREG|0644, st_size=6, ...}) = 0
open("/var/run/yule.pid", O_RDONLY)     = 14
fstat64(14, {st_mode=S_IFREG|0644, st_size=6, ...}) = 0
lseek(14, 0, SEEK_CUR)                  = 0
lseek(14, 0, SEEK_SET)                  = 0
fstat64(14, {st_mode=S_IFREG|0644, st_size=6, ...}) = 0
mmap2(NULL, 6, PROT_READ, MAP_SHARED, 14, 0) = 0xb7bc1000
munmap(0xb7bc1000, 6)                   = 0
close(14)                               = 0
getsid(26060)                           = 26059
munmap(0xb7b85000, 86016)               = 0
chdir("/")                              = 0
umask(022)                              = 022
pwrite64(13, "count|i:202;timestamp|i:11709541"..., 122, 0) = 122
close(13)                               = 0


Many Thanks
Dan

[Stephen Smalley]

On Thu, 2007-02-08 at 17:11 +0000, Dan Track wrote:
>  Ok I just ran your strace and I got two files that contain the
> getsid
>  call. Not sure how to read where the pid is so I'll past a portion of
>  the file incase you can read it better than me. 
It is the argument to getsid, i.e. the number in parentheses.

>  The other strange thing is that I'm not getting any more selinux
>  notifications (SYSCALL) since issuing your chcon command. There are no
>  httpd violations. Should I back out the chcon to get the errors back? 
The selinux notifications are actually the AVC messages; the SYSCALL
records are generated by the audit system if you have system call
auditing enabled when a system call exits if any AVC messages were
emitted during the system call.  The SYSCALL records are helpful in
providing more information, but aren't fundamental to SELinux.

<snip>
>  getsid(26060)                           = 26059 
So it tried to call getsid() on process 26060, and got 26059 as the
session ID of that process.  So look in the traces for 26059 and 26060
to see what those processes were.

-- 
Stephen Smalley
National Security Agency

[Stephen Smalley]

On Thu, 2007-02-08 at 13:55 -0500, Stephen Smalley wrote:
>  On Thu, 2007-02-08 at 17:11 +0000, Dan Track wrote:
>  > Ok I just ran your strace and I got two files that contain the getsid
>  > call. Not sure how to read where the pid is so I'll past a portion of
>  > the file incase you can read it better than me.
>  
>  It is the argument to getsid, i.e. the number in parentheses.
>  
>  > The other strange thing is that I'm not getting any more selinux
>  > notifications (SYSCALL) since issuing your chcon command. There are no
>  > httpd violations. Should I back out the chcon to get the errors back?
>  
>  The selinux notifications are actually the AVC messages; the SYSCALL
>  records are generated by the audit system if you have system call
>  auditing enabled when a system call exits if any AVC messages were
>  emitted during the system call.  The SYSCALL records are helpful in
>  providing more information, but aren't fundamental to SELinux.
>  
>  <snip>
>  > getsid(26060)                           = 26059
>  
>  So it tried to call getsid() on process 26060, and got 26059 as the
>  session ID of that process.  So look in the traces for 26059 and 26060
>  to see what those processes were. 
Actually, you won't have traces for those processes since they weren't
descendants of httpd (since they were unconfined_t, thereby triggering
this getsession avc message in the first place).  But we can actually
infer what the process was from the rest of your trace output - if you
look at your trace, you'll see that it opened /var/run/yule.pid shortly
before calling getsid.    Thus, it is likely trying to check up on the
separate yule daemon process.  Which is likely running in unconfined_t
on your machine.

-- 
Stephen Smalley
National Security Agency

[Dan Track]

On 2/8/07, Stephen Smalley <sds(a)tycho.nsa.gov&gt; wrote:
>  On Thu, 2007-02-08 at 13:55 -0500, Stephen Smalley wrote:
>  > On Thu, 2007-02-08 at 17:11 +0000, Dan Track wrote:
>  > > Ok I just ran your strace and I got two files that contain the getsid
>  > > call. Not sure how to read where the pid is so I'll past a portion of
>  > > the file incase you can read it better than me.
>  >
>  > It is the argument to getsid, i.e. the number in parentheses.
>  >
>  > > The other strange thing is that I'm not getting any more selinux
>  > > notifications (SYSCALL) since issuing your chcon command. There are no
>  > > httpd violations. Should I back out the chcon to get the errors back?
>  >
>  > The selinux notifications are actually the AVC messages; the SYSCALL
>  > records are generated by the audit system if you have system call
>  > auditing enabled when a system call exits if any AVC messages were
>  > emitted during the system call.  The SYSCALL records are helpful in
>  > providing more information, but aren't fundamental to SELinux.
>  >
>  > <snip>
>  > > getsid(26060)                           = 26059
>  >
>  > So it tried to call getsid() on process 26060, and got 26059 as the
>  > session ID of that process.  So look in the traces for 26059 and 26060
>  > to see what those processes were.
>
>  Actually, you won't have traces for those processes since they weren't
>  descendants of httpd (since they were unconfined_t, thereby triggering
>  this getsession avc message in the first place).  But we can actually
>  infer what the process was from the rest of your trace output - if you
>  look at your trace, you'll see that it opened /var/run/yule.pid shortly
>  before calling getsid.    Thus, it is likely trying to check up on the
>  separate yule daemon process.  Which is likely running in unconfined_t
>  on your machine.
>  
Hi

Wow thats a lot info gleaned from the output. So to summarise the
problem is with the httpd type interacting with a process running in
unconfined_t. How would I go about resolving this?

Dan

[Stephen Smalley]

On Fri, 2007-02-09 at 10:22 +0000, Dan Track wrote:
>  On 2/8/07, Stephen Smalley <sds(a)tycho.nsa.gov&gt; wrote:
>  > On Thu, 2007-02-08 at 13:55 -0500, Stephen Smalley wrote:
>  > > On Thu, 2007-02-08 at 17:11 +0000, Dan Track wrote:
>  > > > Ok I just ran your strace and I got two files that contain the getsid
>  > > > call. Not sure how to read where the pid is so I'll past a portion of
>  > > > the file incase you can read it better than me.
>  > >
>  > > It is the argument to getsid, i.e. the number in parentheses.
>  > >
>  > > > The other strange thing is that I'm not getting any more selinux
>  > > > notifications (SYSCALL) since issuing your chcon command. There are no
>  > > > httpd violations. Should I back out the chcon to get the errors back?
>  > >
>  > > The selinux notifications are actually the AVC messages; the SYSCALL
>  > > records are generated by the audit system if you have system call
>  > > auditing enabled when a system call exits if any AVC messages were
>  > > emitted during the system call.  The SYSCALL records are helpful in
>  > > providing more information, but aren't fundamental to SELinux.
>  > >
>  > > <snip>
>  > > > getsid(26060)                           = 26059
>  > >
>  > > So it tried to call getsid() on process 26060, and got 26059 as the
>  > > session ID of that process.  So look in the traces for 26059 and 26060
>  > > to see what those processes were.
>  >
>  > Actually, you won't have traces for those processes since they weren't
>  > descendants of httpd (since they were unconfined_t, thereby triggering
>  > this getsession avc message in the first place).  But we can actually
>  > infer what the process was from the rest of your trace output - if you
>  > look at your trace, you'll see that it opened /var/run/yule.pid shortly
>  > before calling getsid.    Thus, it is likely trying to check up on the
>  > separate yule daemon process.  Which is likely running in unconfined_t
>  > on your machine.
>  >
>  Hi
>  
>  Wow thats a lot info gleaned from the output. So to summarise the
>  problem is with the httpd type interacting with a process running in
>  unconfined_t. How would I go about resolving this? 
Your options are:
1) Ignore it - use dontaudit rules to suppress the avc message.  This is
suitable if it doesn't truly need to interact with the yule daemon.
2) Allow it - use allow rules and adjust the neverallow rule to avoid a
conflict (e.g. change ~sigchld to ~{sigchld getsession}).  This is
suitable if it doesn't expose you to risk.
3) Put the yule daemon into its own domain (i.e. define policy for it),
and then allow httpd_t to interact with that domain rather than with
unconfined_t.

-- 
Stephen Smalley
National Security Agency

[Dan Track]

On 2/9/07, Stephen Smalley <sds(a)tycho.nsa.gov&gt; wrote:
>  On Fri, 2007-02-09 at 10:22 +0000, Dan Track wrote:
>  > On 2/8/07, Stephen Smalley <sds(a)tycho.nsa.gov&gt; wrote:
>  > > On Thu, 2007-02-08 at 13:55 -0500, Stephen Smalley wrote:
>  > > > On Thu, 2007-02-08 at 17:11 +0000, Dan Track wrote:
>  > > > > Ok I just ran your strace and I got two files that contain the
> getsid
>  > > > > call. Not sure how to read where the pid is so I'll past a
> portion of
>  > > > > the file incase you can read it better than me.
>  > > >
>  > > > It is the argument to getsid, i.e. the number in parentheses.
>  > > >
>  > > > > The other strange thing is that I'm not getting any more selinux
>  > > > > notifications (SYSCALL) since issuing your chcon command. There are
> no
>  > > > > httpd violations. Should I back out the chcon to get the errors
> back?
>  > > >
>  > > > The selinux notifications are actually the AVC messages; the SYSCALL
>  > > > records are generated by the audit system if you have system call
>  > > > auditing enabled when a system call exits if any AVC messages were
>  > > > emitted during the system call.  The SYSCALL records are helpful in
>  > > > providing more information, but aren't fundamental to SELinux.
>  > > >
>  > > > <snip>
>  > > > > getsid(26060)                           = 26059
>  > > >
>  > > > So it tried to call getsid() on process 26060, and got 26059 as the
>  > > > session ID of that process.  So look in the traces for 26059 and 26060
>  > > > to see what those processes were.
>  > >
>  > > Actually, you won't have traces for those processes since they weren't
>  > > descendants of httpd (since they were unconfined_t, thereby triggering
>  > > this getsession avc message in the first place).  But we can actually
>  > > infer what the process was from the rest of your trace output - if you
>  > > look at your trace, you'll see that it opened /var/run/yule.pid shortly
>  > > before calling getsid.    Thus, it is likely trying to check up on the
>  > > separate yule daemon process.  Which is likely running in unconfined_t
>  > > on your machine.
>  > >
>  > Hi
>  >
>  > Wow thats a lot info gleaned from the output. So to summarise the
>  > problem is with the httpd type interacting with a process running in
>  > unconfined_t. How would I go about resolving this?
>
>  Your options are:
>  1) Ignore it - use dontaudit rules to suppress the avc message.  This is
>  suitable if it doesn't truly need to interact with the yule daemon.
>  2) Allow it - use allow rules and adjust the neverallow rule to avoid a
>  conflict (e.g. change ~sigchld to ~{sigchld getsession}).  This is
>  suitable if it doesn't expose you to risk.
>  3) Put the yule daemon into its own domain (i.e. define policy for it),
>  and then allow httpd_t to interact with that domain rather than with
>  unconfined_t. 

Hi Stephen,

Many thanks for help with this. I've learnt a lot through this
exercise and I think I can use this as a base to jump off from and
work with selinux with a little more confidence.

FYI I'm going to try option 3, as that seems like the preferred one
with regards to security.

Thanks again
Dan