On Sat, Feb 19, 2011 at 10:17:21PM -0500, Eric wrote:
> On Sun, Feb 13, 2011 at 8:45 PM, Philip Guenther <guent...@gmail.com> wrote:
> > On Sun, Feb 13, 2011 at 8:27 AM, Eric <airu...@gmail.com> wrote:
> >> On (...) Philip Guenther <guent...@gmail.com> wrote:
> >>> (...) if you're intending that this should affect all
> >>> programs without any changes to the program themselves, then this will
> >>> require much care and verification that it doesn't bloat everything.
> >>> Consider that *every* C program on OpenBSD pulls in syslog_r() to
> >>> support the stack-protector check code. If that starts pulling the
> >>> NIS code for getgrgid() to do the gid -> name mapping to find the
> >>> syslog socket, then many binaries will grow.
> >>
> >> I can only think of two ways to avoid having NIS linked into everything:
> >>
> >> - Only use the modified syslog functions though LD_PRELOAD
> >>
> >> - Make openlog/syslog/closelog system calls (this would also allow
> >> us to ensure the accuracy of the pid and program name strings, and
> >> we could filter by program name in syslogd).
> >
> > Yow! Group names are strictly user-space right now; how exactly where
> > you planning on having the kernel get the group name for a process?
> >
> > Backing up a step, syslog_r() MUST remain async-signal-safe, so
> > whatever designs you ponder, please check them against that
> > requirement. That would be true even of an LD_PRELOAD replacement...
>
> I've decided to stay in user-space and stick with group-based
> controls, but I've come across a small problem with modifying openlog
> to find the current process' group:
>
> Daemons like httpd perform openlog before they drop privileges,
> meaning that most daemons would end up logging to
> /dev/syslog_wheel/log. Not that this is such a horrible outcome, but
> it would be nice i these daemons logged to their own sockets.
>
> I'm not sure how to handle this problem, but I thought of two possible
> solutions:
>
> - It might be alright to have the group or perhaps the path of the log
> socket passed as part of the struct syslog_data that's explcitly
> provided by programs that use openlog_r/syslog_r. To get the daemons
> to use this option, we would have to modify each one to use the new
> struct member (many small changes).
syslog() should Just Work - your proposal requires modification of every
daemon and port in a way that only works on OpenBSD.
> - I noticed that the syslog code uses connect() and send() to send
> messages to syslog. I could modify syslog to use sendto()
> instead--Would it be unreasonable to call getresgid and getgrgid for
> each call to syslog()?
getgrgid() isn't signal-safe, so this is not a good idea. It would also
make syslog() quite slow.
> - If each process only had to call getresgid, would that help me avoid
> enlarging each process (avoiding NIS by not using getgrgid/getgrnam?)
> If I did this, I could use the gid_t instead of the group name as the
> path, e.g. /dev/syslog_123/log.
I don't know. Note, however, that all of these things rely on every
process being nice and using syslog() - didn't your first message in
this thread contain the phrase "high integrity log files"? (To spell it
out, syslog() just writes a message to a socket; there are other ways to
do that.)
Backing up a step, pretty much every daemon already has an option to set
the path to /dev/log, and syslog already knows where its sockets are.
Why not just extend /etc/syslog.conf to accept syntax like this:
# Already supported
!sudo
*.* /var/log/sudo
# Extension
:/var/www/dev/log
*.* /var/log/apache
# You may also want to support
127.0.0.1:syslog
*.* /var/log/localhost
You could then do access control via permissions on the socket or the
directory the socket is in. In fact, I'm pretty sure that at least one
of the syslogd replacements in ports already does this.
I'm not convinced that what you're proposing is worth implementing, but
at least the above design is minimally intrusive and may even be
convenient for other uses.
Joachim
