On Fri, 2007-02-09 at 10:22 +0000, Dan Track wrote:
> On 2/8/07, Stephen Smalley <sds@xxxxxxxxxxxxx> 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
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
