Selinux error help - continued

[Stephen Smalley]

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.

-- 
Stephen Smalley
National Security Agency