A few swat comments. was:Re: [Samba] Does the SWAT tool come with the Red Hat 8.0 distribution?

[mark]

On Tue, 11 Mar 2003 07:06:41 +0000 (GMT)
John H Terpstra <jht at samba.org> wrote:


> I like this suggestion. Could you specify your dream wishes more
> clearly please.
> 
> ie: I run SWAT and write the back-up file. Now I run it again and
> overwrite the backup file again? Where is the gain then? Do I only
> back it up if it does not exist? Then what about subsequent changes I
> make? Should it back it up to a file with time and date extensions? If
> so, homw many backups should I keep?
> 
> Your suggestion perplexees me. I want some consensus on this before I
> change anything here.

Consensus?  Dude!  You are a powerful overlord with cvs access!  You
don't need no stinking consensus! 

You are right about the difficulty of figuring out how many times to
back up a smb.conf file.  In the few minutes I've though about it, I
came up with the idea of having swat itself write a few extra bytes at
the top of the file along the lines of "#Swat generated".  or
#0xaed9883344c2a2.  Something to indicate that this file should not be
backed up.  Really what I would like is if I have a smb.conf file that
I've hand edited I would like for smb.conf to back that file up.  So if
a smb.conf file didn't have the above mentioned few bytes it would be
backed up.  

Maybe just a warning along the lines of  "about to overwrite your
smb.conf, would you like to save your original?"

Better yet, dump the entire contents of the smb.conf file into
/var/log/messages every time!  Saved for eternity without the need for
nasty directories filled with smb.conf.1, smb.conf.tar.gz,
smb.conf.original, smb.conf.originalthatreallyworks....Or have swat mail
smb.conf to samba at lists.samba.org so it is archived on the web for when
someone needs it.  Wait.   Did I just digress into the realms of
silliness? I've got to get more sleep.

> But by default, it should be blocked by TCP Wrappers from anything
> except 127.0.0.1. Where is the problem?

Does swat itself edit the hosts.allow file when it is installed?  There
are a couple of issues here, my personal failings as a "sysadmin" (in
quotes because I only do this stuff at home) and a philosophy of
security.

On my failings, I try not to use inetd on machines I have control over. 
 Which means I didn't really know about hosts.allow.  Like I should
have.  But I did spend this morning editing my inetd.conf,
hosts.allow, reading man pages and view the contents of
/var/log/messages in order to understand what was going on.  Live and
learn.  So I just plain didn't know that access could be denied that
way.  

On the philosophy of security, I think that using all interfaces makes
the machine, well, promiscuous.  It just seems like a daemon should do
as little as needed and should show itself as little as possible until
instructed otherwise.  As an example, the *mbd daemons have the
interfaces options in smb.conf.  Why have that option when they can be
run from inetd and thus covered by tcpwrappers?  I assume because we
don't necessarily want those services running on certain interfaces. 
Where they might be exploited in the future by some heretofore unkown
uber-exploit. I just think that swat is in a similar situation.

mark

ps  How do I make umlauts on an english keyboard.  uber-exploit would
look so much cooler with the umlauts.

mark