Date: Tue, 26 Nov 1996 10:42:56 -0600 (CST) From: Joe Greco <jgreco@brasil.moneng.mei.com> To: peter@taronga.com (Peter da Silva) Cc: jkh@time.cdrom.com, bmk@fta.com, jgreco@brasil.moneng.mei.com, brantk@atlas.com, peter@taronga.com, hackers@FreeBSD.org Subject: Re: Replacing sendmail Message-ID: <199611261642.KAA17097@brasil.moneng.mei.com> In-Reply-To: <199611261348.HAA13543@bonkers.taronga.com> from "Peter da Silva" at Nov 26, 96 07:48:58 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > That's why I suggest doing this more incrementally by service type.
>
> But this hasn't got anything to do with services. It has to do with
> security. How about:
>
> security -enable/disable class-of-resources
You guys both have good points but you are thinking too small :-)
The security aspects are certainly a benefit. In the handbook, it can
be made known that is a good idea to do
<whatever_name> -disable ppp
<whatever_name> -disable pppd
<whatever_name> -disable slip
<whatever_name> -disable sendmail
<whatever_name> -disable lpr
<whatever_name> -disable uucp
if those services are not used on a box, which effectively should
eliminate them as a major potential security hole. Peter, I think
we agree on this. :-)
The benefits of a mechanism to select a particular MTA, etc., are also
excellent, as Jordan noted.
Consider these as "layers" on top of a more generalized "subsystem control
mechanism" that doesn't necessarily know or care about any other subsystem.
At the lowest level, you have what I have been talking about: a "package"
(read: subsystem) control mechanism. This need not have too much knowledge
about anything other than the subsystem it is managing. For example,
the "Sendmail" subsystem consists of
sendmail
mailstats
mailq
smrsh
mail.local
sendmail.cf
sendmail.hf
sendmail.st
/var/spool/mqueue
maybe a few other files
Such a mechanism needs to be able to do four things, in my opinion:
1) Install the package. (Perhaps difficult, let's hold this off as
a future improvement for the time being)
2) Enable the package. Make sure permissions are correct. Perhaps
modify /etc/sysconfig appropriately.
3) Disable the package. Make sure permissions are removed. Perhaps
modify /etc/sysconfig appropriately.
4) Uninstall the package. Remove the files and modify /etc/sysconfig.
This may seem trivial, but it may or may not be. In my opinion, making
this an independent module that can properly do this for a particular
subsystem would make a higher level management tool such as Jordan's
mta_select MUCH easier to build. The mta_select function would simply
have to know which MTA's are installed, which one is active, and offer
an appropriate list, or offer to install a currently uninstalled MTA.
A "security" command could simply act as a nice menued front end to
enable or disable subsystems with setuid executables, and maybe other
"questionable" things.
Both of these become trivialized because there is an underlying
foundation to support the generalized functionality of controlling
availability of a subsystem.
See where I am going with this?
"subsystem_control" (arbitrary name) itself might be a shell script no
more complex than this:
% cat subsystem_control
#! /bin/sh -
PATH=/bin:/usr/bin:/usr/sbin:/etc; export PATH
if [ "$#" != "2" ]; then
echo "usage: subsystem_control <command> <subsystem>" 1>&2
exit 1
fi
if [ -d "/usr/share/misc/subsystem_control/${2}" ]; then
# Check for default system components such as Sendmail, LPR, etc.
dir="/usr/share/misc/subsystem_control/${2}"
elif [ -d "/usr/local/share/misc/subsystem_control/${2}" ]; then
# Check for added system components such as Qmail, etc.
dir="/usr/local/share/misc/subsystem_control/${2}"
else
echo "subsystem_control: ${2}: subsystem unknown" 1>&2
exit 1
fi
if [ ! -f "${dir}/${1}" ]; then
echo "subsystem_control: ${1}: function unknown for subsystem ${2}" 1>&2
exit 1
fi
exec "${dir}/${1}"
% cat /usr/share/misc/subsystem_control/sendmail/enable
#! /bin/sh -
PATH=/bin:/usr/bin:/usr/sbin:/etc; export PATH
cd /usr/sbin
mtree -e -U << EOF
/set type=file uid=3 gid=7 mode=0555 nlink=1
. type=dir mode=0755 nlink=2
sendmail uid=0 mode=04555 nlink=3 size=245760
{etc etc etc}
..
EOF
# Somehow enable sendmail within sysconfig
# Maybe start a Sendmail daemon?
exit 0
%
Now, assuming that the maintainer of the Qmail port is willing to devise
a set of {enable,disable} scripts for Qmail, and someone is willing to
devise a set of {enable,disable} scripts for Sendmail, there is now a solid
foundation for availability control, yes?
(And some of us would be more than willing to devise the enable/disable
scripts for things like UUCP, LPR, etc. I volunteer to take a whack at
any "base" subsystem (including Sendmail, UUCP, LPR, PPPD, PPP, SLIP,
R-commands) that uses setuid, as they are ALL security holes.)
In my mind, this is a very simple yet UNIXy way of doing this sort of task.
Abstract and separate the functionality into generalized operations. Then
make building blocks which are more generally useful.
It has to do with security, services, sanity, and all that.
Just another looney tunes idea, but hey, I am now on my home field... ;-)
... JG
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611261642.KAA17097>