Date: Mon, 25 Nov 1996 21:19:04 -0600 (CST) From: Joe Greco <jgreco@brasil.moneng.mei.com> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: jgreco@brasil.moneng.mei.com, brantk@atlas.com, peter@taronga.com, hackers@freebsd.org Subject: Re: Replacing sendmail Message-ID: <199611260319.VAA16166@brasil.moneng.mei.com> In-Reply-To: <8666.848973403@time.cdrom.com> from "Jordan K. Hubbard" at Nov 25, 96 05:56:43 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > It may be. :-) Make sure that you also add a
> >
> > pkg_control -enable sendmail # fix it (unless was removed)
> >
> > too.
>
> I'm not sure that pkg_control is the right interface point, however,
> as it brings up unpleasant connotations of the ioctl() interface which
> is braindamaged enough already. :-)
>
> Perhaps something specifically for controlling mail system behavior
> could be devised, one aspect of which could be MTA selection.
Hi Jordan,
Read the thread :-)
We were talking about a generalized mechanism that could be used to
disable specific portions of the system (or maybe even remove them).
Does it make sense to have the LPD software on a box with no printer
around? Granted it is not a MAJOR security risk, but there have been
security exploits.
Does it make sense to have the SLIP/PPP software on a shell account
server, where they would never be used? I believe a hole in iijppp
has been publicized.
A tool to manage MTA's is acceptable for the purposes of the Great
Sendmail War discussion.
A tool to manage setuid executables (enable/disable such services)
by adding or removing the setuid bits is a nice idea, and somewhat
more useful.
I generalized this even further by extrapolating that at some point,
certain services may be considered totally unnecessary and
inappropriate on a particular type of system.
For example, on a router, it might not make sense to have UUCP, LPR, and
mail services. All three are suid, take up some space, and have nothing
to do with packet routing. This could potentially be considered a
security problem. It is definitely a nuisance for me when I am trying
to squeeze FreeBSD onto a 85MB IDE disk.
What about the compiler? Does it make sense to have the compiler, which
when you consider /usr/include, /usr/lib/*.a, /usr/libexec/cc*, etc.
on a dedicated X workstation? That is a real nuisance in a public
computer lab where the machines are all diskless booted and every effort
is made to secure them.
What I am getting at: FreeBSD has only a vague concept of "optional
system component packages", such as man pages, /usr/dict, etc. Some
of us would like to see this split up further. Lacking a real
infrastructure to do so, maybe a good first step is to at least
target the "components" in question, and design a carving knife that
can deal with them.
Advantages:
1) Enhanced security through reduction of unnecessary setuid programs
on a particular machine.
2) Possibly reduced OS footprint.
3) Allow easy removal of {default system package, i.e. Sendmail} in
favor of alternative replacement {i.e. Qmail/Smail}
4) Provides framework/guidelines for someone to go and build a truly
"componentized" FreeBSD release mechanism. Call it "proof of
concept".
5) Could be extended to work transparently with the existing ports
mechanism.
% cd /usr/ports/mta/qmail
% make
[...]
# make install
[...]
Do you wish to replace Sendmail with Qmail as your default system MTA?
yes
Do you wish to (D)isable or (R)emove Sendmail?
r
#
Disadvantages:
1) Not a real componentized FreeBSD release.
In any case, I would rather NOT see a tool simply to select a MTA and
enable/disable it. If we are going to build a tool, I would rather
see a nice generalized tool that can be extended into other useful
areas.
Comments welcome.
... JG
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611260319.VAA16166>