[gentoo-security] sysklog & syslog-ng: minimizing the number of root user daemons. WAS(Re: [gentoo-hardened] Reducing the number of setuids, root user daemons..et al)

[Miguel Figueiredo Mascarenhas Sousa Filipe]

Hi once more,

On 10/10/06, Miguel Figueiredo Mascarenhas Sousa Filipe
<miguel.filipe@×××××.com> wrote:
> Hi again,
>
> On 10/8/06, Daniel Black <dragonheart@g.o> wrote:
> > On Friday 06 October 2006 01:07, Miguel Figueiredo Mascarenhas Sousa Filipe
> > wrote:
> > > Hi all,
> > >
> > > What do you guys think of:
> > >
> > > - reduce the number of setuid to the maximum
> > > - reduce the number of daemons running has root.
> >
> > Sounds good.
>
> Okay, in that case I will now work a bit on my suggestions and then I will
> post a reply detailing:

Purpose:
Provide safe defaults, apply the least privilege principle, and
introduce privilege separation where possible.


Okay, I took a stab at:
- sysklogd [1]
which was far too easy since gentoo already had the patches I need:
/usr/portage/app-admin/sysklogd/files/sysklogd-1.4.1-caen-owl-klogd-drop-root.diff
/usr/portage/app-admin/sysklogd/files/sysklogd-1.4.1-caen-owl-syslogd-bind.diff
/usr/portage/app-admin/sysklogd/files/sysklogd-1.4.1-caen-owl-syslogd-drop-root.diff

The objective is to make sysklogd run without root privileges
that implies running:
klogd with user: klog, and chroot it in /var/empty (for instance..)
syslogd with user syslog

to do that, we must create the respective users.
Change all files to which syslogd writes (log files) writable by
syslog. I did this by changing the ownership of these files to the
"syslog" user

Also, in /etc/conf.d/sysklogd we must add the following arguments to
each daemon:
klogd:  -u klogd -j /var/empty
syslogd: -u syslog


I also took a stab at:
- syslog-ng [2]
for syslog-ng, the aplication allready supports running has a
unprivileged user, and chrooted.
from the man page:
syslog-ng  [ -C <chroot-dir> ] [ -u <user> ] [ -g <group> ]

the only needed thing is to change /etc/init.d/syslog-ng to read some
config file for syslog-ng (/etc/conf.d/syslog-ng would be nice) and
set there this arguments.

One should say that the privilege revocation on syslog-ng doesn't look
has solid has for sysklogd. The man page refers that will (not) work
depending on several conditions...

And that's it.

Bugs reported:
[1] sysklog: http://bugs.gentoo.org/show_bug.cgi?id=150845
[2] syslog-ng: http://bugs.gentoo.org/show_bug.cgi?id=150844


> - purpose
> - targeted aplications (bugs will be opened)
>   - sysklogd
>   - dhcp3 (dhclient and dhcpd)
>   - vixie-cron
>   - the apps that are setuids because of /etc/shadow.. (I'll have to
> dig more on this)
>   - (not shure, some nfs/rcp apps)
> - modifications needed
> - their impact in increasing security, by reducing the number of
> setuids or root running daemons.
> - their impact on aplication maintenance, system maintenance/administration.
>
> >
> > > has example, openbsd and openwall (among others) both try to have sane
> > > setuids and setguids for things like:
> > > - cron/at service
> > > - syslog and klogd
> > > - passwd (on openwall, not shure about openbsd)
> > > and much more..
> > >
> > > those are the things I miss most, a sane default filesystem system
> > > permissions and a lot of services that can be running without root
> > > privileges..
> > >
> > > One interesting Idea would be to use the /etc/shadow replacement that
> > > is present in openwall
> >
> > Not something I've looked at. Could you describe this a bit more?
>
> I will, in the meantime, let me just point out to the "homepage" of
> the "project":
> http://www.openwall.com/tcb/
> slide show info starting here:
> http://www.openwall.com/presentations/Owl/mgp00020.html
>
> >
> > > anyone knows if any of these things/ideas is being followed, if so,
> > > were can I find pointers to it?
> >
> > for the suid/daemons its generally up to each package maintainer.
> >
> > What I'd suggest is to put in a bug report on how to make each package not
> > suid or root daemon.
>
> I will open bugs to the "affected" aplications, and submit patches
> there, if needed.
>
> >
> > Also look for a place in the gentoo documentation to put these desireable
> > qualities and put some suggested text.
>
> Okay.
>
>
> Much of the focus will be in complementing gentoo-hardened with the
> hardening of specific frequently used subsystems (cron , sysloging,
> shadow related apps/setuids, dhcp ).
> By providing ways to remove their dependency in the root user for
> their correct operation.
> It is a bit "gentoo-hardened" oriented, because mantaining "hardened"
> patches for some aplications might be something their mantainers are
> unwilling to do.
> So, this will also serve to assess the interest of the gentoo-hardened
> comunity in this proposals.
>
>
> Best regards,
>
> --
> Miguel Sousa Filipe
>


-- 
Miguel Sousa Filipe
-- 
gentoo-security@g.o mailing list