Hi once more,
On 10/10/06, Miguel Figueiredo Mascarenhas Sousa Filipe
> Hi again,
> On 10/8/06, Daniel Black <email@example.com> 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:
Provide safe defaults, apply the least privilege principle, and
introduce privilege separation where possible.
Okay, I took a stab at:
- sysklogd 
which was far too easy since gentoo already had the patches I need:
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
Also, in /etc/conf.d/sysklogd we must add the following arguments to
klogd: -u klogd -j /var/empty
syslogd: -u syslog
I also took a stab at:
- syslog-ng 
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.
 sysklog: http://bugs.gentoo.org/show_bug.cgi?id=150845
 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":
> slide show info starting here:
> > > 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.
> 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
firstname.lastname@example.org mailing list