Selinux error help - continued

Dan Track dan.track at gmail.com
Fri Feb 9 14:59:11 UTC 2007


On 2/9/07, Stephen Smalley <sds at tycho.nsa.gov> wrote:
> On Fri, 2007-02-09 at 10:22 +0000, Dan Track wrote:
> > On 2/8/07, Stephen Smalley <sds at tycho.nsa.gov> 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




More information about the selinux mailing list