On 11/16/05, Brad Plant <[EMAIL PROTECTED]> wrote:
On Wed, 2005-11-16 at 12:54 +0100, [EMAIL PROTECTED] wrote:
> > dedicated non-root account. May be we need to ask syslog-ng authors to
> > implement the same scheme as in sysklogd?
>
> Or syslog-ng could have root permissions just for opening /proc/kmsg and then
leave its rights when switching to normal user. But by saying that I make some
assumptions on how /proc/kmsg works and how it must be used.
I ran syslog-ng as a non-root user once before, but now I run it as
root. From what I can remember, syslog-ng opened /proc/kmsg before
dropping privileges, however when you sent the HUP signal (i.e. after
running logrotate) it closed all the files and reopened them again.
Because it no longer had root permissions, it couldn't
reopen /proc/kmsg.
the workaround is to "lseek(0)" instead of closing and open
/proc/kmsg, but doing a lseek in a virtual file li /proc/kmsg is weird
and I don't know it's implications..
Other way, is to simply skip the reopen of /proc/kmsg.
If /proc/kmsg was group readable and the group was set to a special
logger group, then I don't see why syslog-ng couldn't be run as a
non-root user.
that means patching the kernel...
I guess it's better to patch on userland, and leave the kernel to
kernel hackers...
Also, it's cleaner to make the app secure within itselft, instead of
relying on the OS to change the permission and group of /proc/kmsg..
Cheers,
Brad
--
gentoo-security@gentoo.org mailing list
Best regards,
--
Miguel Sousa Filipe
--
gentoo-security@gentoo.org mailing list
