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):
/bin /sbin /root
you forgot /usr/local/indecisive/obscurely_secure/\ /.Sissel/bin
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
? _______________________________________________
I would probably make a /root/bin directory and put it in there.
Brad Crotchett brad@bradandkim.net http://www.bradandkim.net
On 7/18/07, James Sissel jimsissel@yahoo.com 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. 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
/root/bin/*
djgoku wrote:
On 7/18/07, James Sissel jimsissel@yahoo.com 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. 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
/root/bin/* _______________________________________________ Kclug mailing list Kclug@kclug.org http://kclug.org/mailman/listinfo/kclug
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
-Scott Oertel
I've written a Perl program to parse my /var/log/messages file and place certain data into a mySQL database.
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:
I've written a Perl program to parse my /var/log/messages file and place certain data into a mySQL database.
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.)
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:
/home/Logcooker/binWell, 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
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?
David Nicol wrote:
On 7/20/07, Scott Oertel freebsd@scottevil.com wrote:
/home/Logcooker/binWell, 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
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?
I just don't see the problem really with having a script inside /root/bin, which is completely locked down to only the root user, which parses logs via a cron job. I just don't see the harm.
-Scott Oertel
On 7/20/07, Scott Oertel freebsd@scottevil.com wrote:
I just don't see the problem really with having a script inside /root/bin, which is completely locked down to only the root user, which parses logs via a cron job. I just don't see the harm.
-Scott Oertel
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:
David Nicol wrote:
On 7/20/07, Scott Oertel freebsd@scottevil.com
wrote:
/home/Logcooker/binWell, this would be more secure, ...
I just don't see the problem really with having a script inside /root/bin, which is completely locked down to only the root user, which parses logs via a cron job. I just don't see the harm.
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
I just don't see the problem really with having a script inside /root/bin, which is completely locked down to only the root user, which parses logs via a cron job. I just don't see the harm.
I would have to concur on this. Only a user who has hijacked the root account will be able to mess with this script.
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:
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
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:
/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. _______________________________________________ Kclug mailing list Kclug@kclug.org http://kclug.org/mailman/listinfo/kclug
On Jul 18, 2007, at 11:38 AM, James Sissel 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. 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
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
I personally would drop it in /etc/cron.daily
~Bradley
James Sissel 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. 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
?
Kclug mailing list Kclug@kclug.org http://kclug.org/mailman/listinfo/kclug
On 7/20/07, Jonathan Hutchins hutchins@tarcanfel.org wrote:
On Friday 20 July 2007 11:00:58 am Bradley Hook wrote:
I personally would drop it in /etc/cron.daily
Actual scripts and programs should not go there. Either symbolic links to scripts, or simple calls to programs with options.
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