syslog from chrooted environment

[halfdog]

Phil Pennock writes:
> On 2017-07-25 at 09:31 -0400, Mike Tancsa wrote:
> > On 7/24/2017 8:39 PM, Nico Kadel-Garcia wrote:
> > > Why are the targets of the hardlinks evaporating on rebooting? Is that
> > > a FreeBSD'ism?
> >
> > Its when syslogd stops/starts. The hardlinks need to be recreated for
> > some reason.
>
> Because /dev/log is a symlink to /var/run/log which is a Unix-domain
> socket, created by whatever listens for connections.
>
> You'll want to use syslogd_flags="..." in /etc/rc.conf to add a bunch of
> <-l location> pairs.  Or create a new rc.d script to create the
> hardlinks if you're wedded to that, and use the rcorder keywords to have
> ssh depend upon it, etc.
>
> Honestly, I'd start looking instead at having syslogd listen on a UDP
> socket on a non-routed address and send to that locally instead. See
> the "-a" option to syslogd, although contrary to docs my past experience
> has suggested that -a can't be repeated.

What about trying to pass the fd directly, where appropriate,
i.e. 1) the subcomponent supports it to use syslog that way,
2) there is no fork/chroot involved that may make it hard to know,
what the file descriptors were for and 3) there are no additional
security risks associated with that behaviour.

In remaining cases, where subcomponent would support that, define
some environt variable, e.g. "_SSH_SYSLOG_TARGET_SPEC", which
is "fd:[num]" for the most simple case, other might follow, perhaps
"udp:[ip]:[port]" or "scm-rights:[receiver-fd]"?

That could be very generic, also supporting SSH subcomponents
invoked via "execve". Subcommands (or wrappers) may even use the
variable to create hardlinks or forwarders before invoking the
final command, so that they do not require SELinux/AppArmor and
alike to give them privileges to do so.

hd