Slashdot Mirror
SDSC Secure Syslog
Wee writes "I saw this morning that the San Diego Supercomputer Center has released Secure Syslog, a replacement for the standard Linux/UNIX syslog daemon they've been working on for some time. It adds security and performance features (modular design, highly scalable), while retaining backwards compatibility. According to their announcement, it is the first syslog implementation to target "syslog-reliable" (RFC 3195) functionality and it is the first syslog targeted at very high performance and forensically-sound auditing. It's currently under the UC's "free for non-commercial use" license, but they are looking at moving to a completely open license (BSD-style licensing was mentioned). If you have high-traffic systems and you need reliable syslogging, this might be a worth a look. Those needing syslogging over TCP/BEEP, sockets, etc as well as UDP might also want to check it out."
The question on my mind, and probably other peoples' minds is does this work with the Nintendo 64?
If it's meant for high-traffic zones, why would it be currently available for non-commercial use first? Ah, I get it, yet again using the public as guinea pigs. You know Gates has to be behind this one. (last part of comment meant to be humerous)
~~{~~@ LDP @~~}~~
...like syslog, for instance. Very extensible, appropriately hieroglyphic configuration, arbitrary manner of operation... it had everything a successful Unix daemon needs.
Except security. Welcome to the 21st Century, syslog.
huh?
try www2.drury.edu/philip ...
FYI, this is BEEP
No, it's not Captain Pike's YES/NO beeps
"I would say that 99 per cent of what my father has written about his own life is false." - L. Ron Hubbard Jr.
free for slow adoption.
the sooner more people can use it, the sooner corporate products will have to support it, and the more secure we all can hopefully be.
after all, we haven't had much luck getting the newer snmp versions deployed.
ostiguy
I suspect that many of the top corporations may find a use for this in wake of all of the "Oops, I lost that important file!" scandals, and the need to trace steps of hackers too.
I see a great future in this and the products that come after it. Kudos to the developers!
I've been looking for just this and all that I have been able to come up with are funny, unsupported hacks that lack backwards compatibility. This looks perfect! Now, will it compile without any changes under HP-UX?
If you need syslogging over TCP and want a *way* more configurable system for filtering syslog destinations, including regex filtering and per-host routing, you might want to look at syslog-ng. It works great for me, and is already GPL'ed, so no waiting for a license change.
"I feel that if a person can't communicate, the very least he can do is to shut up." -- Tom Lehrer
"a replacement for the standard Linux/UNIX syslog daemon they've been working on for some time....it's currently under the UC's "free for non-commercial use" license, but they are looking at moving to a completely open license (BSD-style licensing was mentioned)."
Sorry to sound like a weenie, but if its not GPL'd I'm not interested. This is one of those "core parts" I'm usually talking about that needs to be gpl if its going to get included in every distro. I know there are important parts of every linux distro that aren't GPL, but the more software we add that isn't GPL the worse off we are. Don't get me wrong, I'm all for proprietary add-on software(desktop/server apps, games etc) for linux, but the core software, ie base OS, system utilities, desktop WM, internet browser/connection software and basic office capabilities need to be GPL.
If you wanna get rich, you know that payback is a bitch
Set up a locked down host on your network (no services running) except for syslogd. Then other hosts can use remote logging to log to this host. In case of even a widespread system compromise, your locked down logging host is completely safe and your logs can be obtained through console login.
See section "SUPPORT FOR REMOTE LOGGING" in man syslogd.
And as long as you remember root can't have any shell other than
And of course you understand the next maintenance pack from HP will contain a depot that will overwrite key libraries without warning and break the thing completely.
In short, it works just as well on HP-UX as anything else does.
Feel my pain. I admin many large HP-UX machines.
as a software developer at UCSD/SDSC I know it can be very difficult to get the folks in the UCSD offices to agree to GPL. Difficult, but not impossible. I would expect that it will happen eventually. :) (way to go team!)
Wow did anyone else notice the Brazil references in RFC 3195?
It's good to know that geek culture still persists and can perimate into even the most serious subjects.
- Serge Wroclawski
What do you use for webserving?
What about database service? MySQL has poor functionality in the fully-GPL version, and PostgreSQL is BSD-licensed.
Either you're an idiot or you're trolling. There is no in between. Personally, I think you're an idiot.
Remember that what's inside of you doesn't matter because nobody can see it.
... to help your ISP to maintain massive logs of your online activities, neatly packaged for law enforcement and other "authorities".
Thanks!
Tuus crepidae innexilis sunt.
Modular!
/dev/null is all the syslog I need!
Scalable!
Backwards compatible!
Linux!
RFC 3195 functionality!
high performance!
forensically-sound auditing!
If only it was vertically integrated. Oh well, better luck next time!
till then,
I don't need no instructions to know how to rock!!!!
Standard syslog has several problems which I think are quite serious.
Remote logging is a joke. There is no authentication, and no notification whatsoever that the event was received by the remote syslog daemon. An attacker can fill the remote syslog with garbage data if they so choose.
The records are entirely unstructured and not validated. The timestamp, hostname, and process id are all volunteered by the application, not something that's noted by syslogd.
There is no guarantee whatsoever that an application that has called syslog() will have its messages safely recorded when the function returns. I'm not talking safely tucked away on disk if the system crashes, but even written into the buffer cache by syslogd when syslog(3) returns. See end of post for details.
If syslog's receive buffer is full, syslog(3) will block. This means that if syslogd cannot keep up with the rate of messages, which is a really easy condition to find yourself in given that by default syslogd calls fsync() after every log file update, your system will slow to a crawl. You cannot even login(1) since most systems record this activity to security logs.
P.S. syslog() returns as quickly as possible. Try an experiment. Generate a random number, call syslog() with this number as a string, and then open() /var/log/messages, seek to the end minus 4096 bytes. Try to find the random number. I have tried it 20 times and never has the number been there by the time read() was called. It takes longer than an application doing syslog()/open()/lseek()/read() for syslogd to record it into to the buffer-cache, let alone fsync() it to disk.
Copyright 2002 The Regents of the University of California All Rights Reserved
Permission to use, copy, modify and distribute any part of this SDSC-syslog program for educational, research and non-profit purposes, without fee, and without a written agreement is hereby granted, provided that the above copyright notice, this paragraph and the following paragraphs appear in all copies.
Those desiring to incorporate this SDSC-syslog program into commercial products or use for commercial purposes should contact the Technology Transfer Office, University of California, San Diego, 9500 Gilman Drive, La Jolla, CA 92093-0910, Ph: (619) 534-5815, FAX: (619) 534-7345.
IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY PARTY FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, INCLUDING LOST PROFITS, ARISING OUT OF THE USE OF THIS SDSC-syslog PROGRAM, EVEN IF THE UNIVERSITY OF CALIFORNIA HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
THE SDSC-syslog SOFTWARE PROVIDED HEREIN IS ON AN "AS IS" BASIS, AND THE UNIVERSITY OF CALIFORNIA HAS NO OBLIGATION TO PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS. THE UNIVERSITY OF CALIFORNIA MAKES NO REPRESENTATIONS AND EXTENDS NO WARRANTIES OF ANY KIND, EITHER IMPLIED OR EXPRESS, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, OR THAT THE USE OF THE SDSC-syslog SOFTWARE WILL NOT INFRINGE ANY PATENT, TRADEMARK OR OTHER RIGHTS.
SDSC-syslog is developed by Tom Perrine at San Diego Supercomputer Center at the University of California, San Diego. Support for this effort is provided by Commerce Net (CN-NGI01-009).
After some not-so-trivial digging, I found the UC guidelines for releasing software. Essentially, any software written by a UC employee can be made "public" as long as procedures are followed and it's released for non-commercial use (with a license statement accompanying the software stating such).
Bash away at the software's non-GPLness, but I for one think it's pretty spiffy that anything a UC faculty, student of staff member writes can be given away, in source form, to the public. Anyone who works in the private sector who is allowed give away software written on the corporate dime can either speak up or hush up.
Anyway, cut 'em a little slack, would ya? They're trying.
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
how the fuck is this troll but it's parent interesting?
it's the exact same language except for the "gpl sucks" at the end
Anybody have any more info about if and when the license might change?
Why?
I've had this sig for three days.
The UC guidelines webpage in the parent article's link says free for "educational, nonprofit and research purposes" and requires permission to incorporate the software into commercial products but this new syslog's document adds "...or use for commercial purposes" as a restriction. If I am the network admin for a small city local govt, it using this software internally for my own needs deemed to be "for commercial use" now?
Corporate Gadfly
Jonathan Archer: the most beaten up Enterprise captain in Star Trek history
The Nintendo 64 has inadequate power for this to support multiple hosts. The PS/2 however, is capable of supporting up to 10 hosts.
> Feel my pain. I admin many large HP-UX machines.
I can feel your pain soooo good...
On a long enough timeline, the survival rate for everyone drops to zero.
syslog-ng is nice, it has the advantages of TCP and a smart filtering scheme, but that's all. For example, logging to SQL is very weak, it's more like a hack.
For example, a syslog version that does everything syslog-ng does, and more, and has decent SQL logging, and a sound security mechanism (PEO) is msyslog
However, even msyslog is quite simplistic when compared to sdscsyslog. IMO, sdscsyslog has an extremely intelligent architecture, that allows for easy expansion, and easy implementation of features that neither syslog-ng nor msyslog can dream of.
Feel my pain. I admin many large HP-UX machines.
To quote Bill (the Cat) "BLLLLFFFTTT"
If you want Pain then try using AIX...
I do remember seeing a piece of advice for those wishing to become System Administrators...
Find an OS that you hate... Congratulations, you will be working with it for the rest of your life.
After Solaris, I thought HP-UX was bad... Not awful, but bad... Now I deal with AIX...
Z... Admin of AIX, HP-UX, Solaris and Linux boxes... I try to forget the SCO machines.
-- Under/Overrated is meta-moderation, and therefore is Redundant.
Another problem with DNS is that your logs can be "poisoned". DoS attack is a smaller problem when compare to poisoning.
Although it's nice to see people attempting to improve one of the more regularly broken unix core services, I still think that the whole syslog design of a monolithic central multiplexed logging daemon is the Wrong Design.
Dan Bernstein's multilog, from his daemontools package, is, in my opinion, a good example of the correct way to do logging: a single process logs the stdout and stderr of each daemon, goes to great lengths to ensure that no data is lost, and handles logfile rollover automatically. With this tcpserver/tcpclient utilities from his ucspi-tcp package, it can be simply done over a network as well.
Of course, DJB's code, while source-available, is not in any way Free Software, and daemontools in particular currently is inextricably linked into his extraordinarily dubious "slashpackage" system, making it a potentially annoying choice for anyone reselling or distributing systems based on it. Cronolog, which was originally created to manage apache logs, looks like a promising GPLed replacement for multilog, but despite lots of grumbling along those lines, nobody has written a gpl/bsd replacement for daemontools...yet.
News for Nerds. Stuff that Matters? Like hell.
It's very funny, only yesterday i published on a mailing list my proposal for a new syslog daemon architecture:
:-)
Syslog Daemon Architecture
I wrote this document for the msyslog project.
And then, today, i noticed the sdscsyslog announcement on Slashdot!
There are many similarities between their architecture and my proposal:
- modularity
- extensibility
- scalability, etc.
This is again another problem with open source projects. Lack coordination amoungst projects. How many sub-systems does it take to do the same unit of work?
We have syslog, syslog-ng, a proposal for msyslog, this new version from the university system.
All this does is prove to the M$ marketing machines that opensource has no teeth, let alone coordinated ability to ensure redundant work does not happen.
So where's the compare/contrast to all that came before that convinces people any one of the proposed solutoin is the superior to the previous and its time to move up the IT evolutionary chain.
If we used the same efforts used in open source to supply gas stations there would exist 100+ recipies for grades of fuel and a creeky still & cracking tower would have to be setup next to the gas pump. Until someone took upon the entrepreneurial challenge it wouldn't come out of the spout for consumers. -- until then it would remain something you would have to assemble yourself.
Yet another example of cowboy IT development shooting its own industry in the foot.
I get ice in my belly when I imagine someone poking such a savage hole in my thesis like that. His confidence prior to this scandal just exacerbates the situation.
Well, not exactly.
The traditional syslog is old, broken and dying. It doesn't count.
syslog-ng is cute and has TCP and clever message filtering. But that's all.
msyslog goes beyond that and adds true and reliable SQL logging (SQL in syslog-ng is a joke), PEO message protection (tamper-evident) and a somewhat more extensible implementation. But it stops there.
sdscsyslog is the first attempt to solve all the problems with all the other implementations, and also adds long-awaited features. However, it does not overlap with my proposal, because mine is just... heh, just a proposal, while they already have a running application.
But i agree with you. There is some fragmentation in the Open Source / Free Software world.
Does anyone else find it somewhat amusing that nearly every story about a core unix process, be it an improvement or a security notice, features a thread promoting some DJB utility?
Even more amusing is the obligatory disclaimer about how annoying DJB and his licenses are, the absence of development on some of the packages (djbdns comes to mind), or some other quirk that makes them difficult to replace what's already there.
sdscsyslogd-1.0.0 RC4 does not compile on Solaris 8, nor on FreeBSD.
../../src/message/message.h:25, ../../src/outputmod/outputmod.h:23, ../../src/include/chaninfo.h:23, ../../src/include/chaninfo.h:23,
The 'configure' script does not report any problems, and correctly detects the operating system. FreeBSD has some problems with the 'sed' substitutions for "include/const.h".
Using GCC on either platform, the compile pukes in "src/util/netaddr.h". It appears that SDSC syslogd can only successfully compile on Linux, due to use of Linux-specific socket structure declarations in this file?
gcc -DHAVE_CONFIG_H -I. -I. -I../../src/include -I../../src -g -Wall -Wno-inl
ine -Wstrict-prototypes -O2 -pedantic -c `test -f config.c || echo './'`config.
c
In file included from
from
from
from config.c:19:
../../src/util/netaddr.h:98: field `sa' has incomplete type
../../src/util/netaddr.h:99: warning: ISO C doesn't support unnamed structs/unio
ns
../../src/util/netaddr.h:99: warning: no semicolon at end of struct or union
../../src/util/netaddr.h:99: parse error before numeric constant
../../src/util/netaddr.h:100: warning: built-in function `sin' declared as non-f
unction
../../src/util/netaddr.h:102: parse error before '}' token
../../src/util/netaddr.h:102: warning: ISO C does not allow extra `;' outside of
a function
In file included from
from config.c:19:
../../src/outputmod/outputmod.h:75: field `sendTo' has incomplete type
../../src/outputmod/outputmod.h:82: confused by earlier errors, bailing out
I do not deploy Linux. Ever.
Just look at the code. It's all "check that we have enough size", "copy that much data there", etc. It's all too easy to make mistakes with that. I found two missing checks, non-exploitable though. Also I found another almost-exploitable overflow with it's IPC, it used malloc(len) instead malloc(len*4). Only reason it's not exploitable is that the length was always either 0 or 1.
vsftpd handles buffers the right way - quoting security/implementation doc:
That was UDP, not DNS.
Silly braintypo...
but it doesn't work on my Xbox.
What a load of trash!!
I think many people could do themselves a great service by simply studying the vsftpd security libraries. Those are generic enough to be used by almost any other application, and provide a solid foundation to write applications that do not fall apart under classic C exploits: buffer overflows, etc.
Check here the vsftpd website.
do we really need specialized encryption built into each application? why not just use something at the stack level?
Boo-yah~!
Don't get me wrong, I'm all for proprietary add-on software(desktop/server apps, games etc) for linux
Yeah, the BSD license is so very proprietary. So proprietary, in fact, that you can take BSD-licensed code, modify it, and release the result under GPL. Doesn't get much more non-free than that.
Sheesh, the GPL zealots never fail to astound me...
....syslog-ng, also verify non-spoofed ip address and there it is, almost perfect (if your front server is compromised though, your syslog can still be DOS's, though not poisonable (no rewind there)...
NO SIG
For the license.
If this product were to be released under a Free-software license I'd definately consider it on our network. As it is I (and probably many others) will use something else like syslong-ng or metalog, despite the fact that SDSC-syslog seems to be far more technically competent.
Blaming GW Bush for the Iraq war is like blaming Ronald McDonald for the poor quality of food.
As usual, this being a 1.3.x release, I haven't even compiled this
kernel yet. So if it works, you should be doubly impressed.
-- Linus Torvalds, announcing kernel 1.3.3
- this post brought to you by the Automated Last Post Generator...