I'm using Ubuntu 6.06 for my web server. I've written a Perl program to parse my /var/log/messages file and place certain data into a mySQL database. I use PHP to read that database and create a nice webpage for myself to I can check the log easily. The question is, where should I place the Perl program? It should only be run as root and I'd like to create a daily cron job to run it. Options are (among others):
/bin /sbin /root
?
More fun this way. And I get practice using Perl, PHP, and CSS.
Luke -Jr luke@dashjr.org wrote: > I'm using Ubuntu 6.06 for my web server. I've written a Perl program to
parse my /var/log/messages file and place certain data into a mySQL database.
Um, why not hack your syslog daemon to do that live?
On 7/18/07, James Sissel jimsissel@yahoo.com wrote: Options are (among others):
you forgot /usr/local/indecisive/obscurely_secure/\ /.Sissel/bin
I would probably make a /root/bin directory and put it in there.
Brad Crotchett brad@bradandkim.net http://www.bradandkim.net
I agree, any script that I write the performs a system function and is not part of the provisioning system usually goes in /root/bin
Seriously, the more secure approach as I understand it is to create a special-purpose user and have the process run by that user. For clarity's sake, the script would then live somewhere like
/home/Logcooker/bin
(I capitalize fake users, to avoid confusion in case I have to give a user account on this machine to someone strongly identified with their hobby as an amateur paper miller.)
David Nicol wrote:
Well, this would be more secure, provided you have a specially crafted sudoer's file for that "Logcooker" user so that they may access the logs, although after some period of creating maintenance scripts the sudo file will start to get very very large and complicated, leaving you with a user that has nearly the same as root privileges
-Scott Oertel
On 7/20/07, Scott Oertel freebsd@scottevil.com wrote:
no, no, no -- use group permissions. Although the way people use sudo, you'd think they'd just go ahead and use all the SEL features. The inside-out thinking required to use groups effectively is a genuine usability barrier.
Did anyone from that crazy summer class at ITT I taught earlier this year actually sign up for this mailing list like I encouraged them to do?
On 7/20/07, Scott Oertel freebsd@scottevil.com wrote:
If there was an unknown exploit in your log processing tool, and that hole could be exploited by inserting a string into one of the logs that was processed by your tool, a string could be inserted into the log some how -- inserting strings into logs is certainly possible with web server logs, for instance, that log the user agent, for instance -- the exploit could be exploited. This is "theoretical exploit" territory, of course, which is a kind of endless flat-earth sort of debate -- the question is, is "completely locking down" any computer program possible.
--- Scott Oertel freebsd@scottevil.com wrote:
I would have to concur on this. Only a user who has hijacked the root account will be able to mess with this script. If the root account is compriomised then security is moot. However, if I were writing a script to parse the log files, I would save the output under a different account, so that those files didn't become a security issue. Unless, only root should be looking at the output. But then root really shouldn't be logged onto the system doing anything, except system maintenance.
IMHO, Brian
Let's say there's a deliberate back-door in, let's say, bash, so that whenever the input buffer has "xyzzy ..." in it, there's a vfork and ... gets passed to the child shell instance. That kind of string would be easy to get into a log file. Http agent strings, for instnace, can be anything. The problem is eliminating possible ways to hijack the root account. Log data is tainted. By tainted I mean that it can have arbitrary stranger-provided data in it. If the log cooking system runs as a non-root user, an exploit in log data (which might not be possible -- if all the logs contain is internally generated statistics and error messages, no externally provided texts, than this particular scenario would not apply -- could lead to a root breach.
This scenario is also an argument for centralized log processing; which standard syslog facilities provide OOTB, but I for one have never seen them actually set up.
Anyone else on this list actually doing network syslogging to a central log server?
On 7/18/07, James Sissel jimsissel@yahoo.com wrote:
http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
/usr/sbin/ -- Non-essential system binaries (e.g. daemons for various network-services).
or
/usr/local/bin/
/usr/local is where anything hand-installed should go. If you are writing a package, /usr is probably appropriate. / is only for stuff you need in a disaster situation.
I've always opted for users' scripts in their ~/bin directories, but I really like David Nicol's suggesting. How about something like:
you forgot /usr/local/indecisive/obscurely_secure/\ /.Sissel/..\ /bin
:)
On 7/18/07, Luke -Jr luke@dashjr.org wrote:
On Jul 18, 2007, at 11:38 AM, James Sissel wrote:
http://www.pathname.com/fhs/pub/fhs-2.3.html
Sincerely,
William
where'e the entry for
/\ / Rootkits Purpose
probably a good thing that's not a wiki
On 7/20/07, Jonathan Hutchins hutchins@tarcanfel.org wrote:
perl -le 'print q{But what does "simple" mean?}'
-
brad＠bradandkim.net -
Bradley Hook -
Dave Hull -
David Nicol -
djgoku -
Jack -
James Sissel -
jim＠jimani.com -
Jonathan Hutchins -
Luke -Jr -
Scott Oertel -
William Harrington