rc.local question/problem

[Cameron Simpson]

On 02Jul2011 22:24, Paul Allen Newell <pnewell at cs.cmu.edu> wrote:
| inline and at tail ...

As things should be :-)

| On 7/2/2011 9:45 PM, Cameron Simpson wrote:
| >On 02Jul2011 20:40, Paul Allen Newell<pnewell at cs.cmu.edu>  wrote:
[...]
| >Thought: is clamscan setuid or something?
| >If you get nowhere there, try stracing the clamscan run:
| >   strace -e trace=file /usr/bin/clamscan ...args..here...  2>/root/strace.out
| >and you should get to see exactly what clamscan is doing, filewise.
| 
| Not certain about this last bit .. are your suggesting that I put
| the strace command in the rc.local?

I was thinking of putting it in the virus-scan.sh script; just modify
the /usr/bin/clamscan line with "strace -e trace=file" at the start and
"2>/root/strace.out" on the end. The strace.out should have every
attempted open/close/stat etc.

| As for the "setuid" comment, I
| need to plead ignorance and ask not only for a bit of education
| about what you are saying but a guide as to how to ascertain what
| you are questioning.

"setuid" is the UNIX priviledge mechanism. There's a wiki article here:
  http://en.wikipedia.org/wiki/Setuid
but in short, a setuid program has the "s" bit set for the user field.
When you execute such a program, the program itself runs as the user
that owns the program file, not the user invoking the program.

So if clamscan were setuid it may not, itself, run as root.

However this is unlikely because I'd expect a virus scanner not normally to
want a special user, and also this wouldn't change the behaviour if run from
rc.local instead of elsewhere.

[...snip...]
| #/usr/bin/clamscan -ri $COMMON_DIRS --log="$CLAM_LOG" | mail -s virus-scan.`date +%d%b%y_%k%M` root at localhost paul at localhost
| /usr/bin/clamscan -ri $COMMON_DIRS_1 --log="$CLAM_LOG" | mail -s virus-scan_1.`date +%d%b%y_%k%M` root at localhost paul at localhost
| /usr/bin/clamscan -v --debug -ri $COMMON_DIRS_2 --log="$CLAM_LOG" | mail -s virus-scan_2.`date +%d%b%y_%k%M` root at localhost paul at localhost
| /usr/bin/clamscan -v --debug -ri $COMMON_DIRS_3 --log="$CLAM_LOG" | mail -s virus-scan_3.`date +%d%b%y_%k%M` root at localhost paul at localhost

I see you have several clamscan runs. If you use strace, put the outputs
in distinct files.

[...]
| freshclam -d -c 2 -l /var/log/clam-update.log
| #/root/virus-scan.sh > dev/null 2>&1
| /root/virus-scan.sh >/root/rc-local-virus.out 2>/root/rc-local-virus.err

Looks good to me.

| + pwd
| + id
| + CLAM_LOG=/var/log/clamscan.log
| + '[' '!' -f /var/log/clamscan.log ']'
| + COMMON_DIRS_1='/bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin'
| + COMMON_DIRS_2=/home
| + COMMON_DIRS_3=/tmp
| + /usr/bin/clamscan -ri /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin --log=/var/log/clamscan.log
| ++ date +%d%b%y_%k%M
| + mail -s virus-scan_1.02Jul11_2202 root at localhost paul at localhost
| + /usr/bin/clamscan -v --debug -ri /home --log=/var/log/clamscan.log
| ++ date +%d%b%y_%k%M
| + mail -s virus-scan_2.02Jul11_2202 root at localhost paul at localhost
| + /usr/bin/clamscan -v --debug -ri /tmp --log=/var/log/clamscan.log
| ++ date +%d%b%y_%k%M
| + mail -s virus-scan_3.02Jul11_2202 root at localhost paul at localhost

| /
| uid=0(root) gid=0(root) groups=0(root) context=system_u:system_r:initrc_t:s0

Ok, so no error messages appear in the output so we learn little.
We do see that the program is indeed running as root.

At this point I'd turn off selinux briefly for a test run.
Maybe modify rc.local thus:

  setenforce 0
  ... the virus scan stuff ...
  setenforce 1

and run it by hand or via the reboot.

If you can establish that disabling selinux makes it work then you can
proceed to make special rules for that (or run without selinux; probably
not in keeping with your security stance).

A handy redhat box has the directory /var/log/setroubleshoot with log
files in it. They may be relevant. In fact, if you can make it fail from
the command lines as root, you could:

  tail -F /var/log/setroubleshoot/setroubleshootd.log

while running a failure. (/var/log/secure, /var/log/messages may also be
interesting).

Cheers,
-- 
Cameron Simpson <cs at zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

So YOU recant your IRRATIONAL Assertion right now or we will not LIKE
YOU any more.   - drieux