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 fedora-selinux-list mailing list