Hi once more,
On 10/10/06, Miguel Figueiredo Mascarenhas Sousa Filipe
<[EMAIL PROTECTED]> wrote:
Hi again,
On 10/8/06, Daniel Black <[EMAIL PROTECTED]> 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
--
[email protected] mailing list
