Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 23 Apr 1998 03:54:21 +0800
From:      Peter Wemm <peter@netplex.com.au>
To:        Poul-Henning Kamp <phk@critter.freebsd.dk>
Cc:        "Rodney W. Grimes" <rgrimes@GndRsh.aac.dev.com>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, cvs-usrsbin@FreeBSD.ORG, soren@dt.dk
Subject:   Re: cvs commit: src/usr.sbin/syslogd syslogd.c
Message-ID:  <199804221954.DAA12177@spinner.netplex.com.au>
In-Reply-To: Your message of "Wed, 22 Apr 1998 20:47:34 %2B0200." <4371.893270854@critter.freebsd.dk>

next in thread | previous in thread | raw e-mail | index | archive | help
Poul-Henning Kamp wrote:
> In message <199804221810.LAA07748@GndRsh.aac.dev.com>, "Rodney W. Grimes" wri
    tes:
> >> 
> >> Hmmmm,
> >> 
> >> Now, I'm not too sure what people use SecureMode for, but it doesn't
> >> make sense to expect one host to accept remote logging from other
> >> hosts that don't, at least in my book...
> >
> >Your book may not involve a large AS of systems that remotely syslog to
> >a central syslog server.  All ``syslog clients'' run in syslogd -s mode,
> >the ``syslog server'' runs in normal syslogd mode, but has ipfw setup
> >such that it only accepts syslog packets from a trusted list of clients.
> 
> Well, for the ipfw to work, wouldn't the socket need to be bound to 
> a well-known-port then ?  That was the fact that made me conclude that
> you couldn't do the above scenario in the first place.

If you run in -s mode, syslogd doesn't bind(), so it *cannot* receive
packets, period.  -s mode is "do not listen" to the network, it's not 
supposed to stop that instance of syslogd from sending.

> I would think that all securemode should do would be to not include the
> fd in what select is watching, but the code before this change also
> diked out the bind, so you wouldn't know what port you would be sending
> syslog messages from, making ipfw unable to decide if the message came
> from syslogd or some random user...

Securemode stops the bind() and the select().  ipfw is irrelevant in 
-s mode since it doesn't receive data.  The socket is only used for 
sendto().  It's created and kept around so that syslogd can't ever get 
stuck trying to send a critical log message over the network but fail 
because all fd's are in use.

You use ipfw or syslogd's internal masks (see -a flag) without the -s flag 
in order to safely get logs from other syslogds over the network.

-s was working exactly as indented (and documented) before (although the
code was messy, I'll grant you that. :-)

>From the FM:
     -s      Operate in secure mode.  Do not listen for log message from re-
             mote machines.
Nowhere does it imply that -s make syslogd fail to process the @loghost 
syslog.conf directives.

On the client machines, you use -s and divert important logs to the server.

On the server machine(s), you use -a and/or ipfw to limit where you'll 
accept packets from.

Argueably, syslogd should not listen by default and should require a switch
to activate network listening, but that breaks POLA when people do a 'make
world' or upgrade.  (this is the same reason why named still has a path to
/etc/named.boot compiled into it, and yet we have shipped /etc/namedb/
named.boot for ages...  People don't often update their /etc stuff.)

> --
> Poul-Henning Kamp             FreeBSD coreteam member
> phk@FreeBSD.ORG               "Real hackers run -current on their laptop."
> "Drink MONO-tonic, it goes down but it will NEVER come back up!"
> 

Cheers,
-Peter
--
Peter Wemm <peter@netplex.com.au>   Netplex Consulting



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199804221954.DAA12177>