I am trying to run clamav from rc.local so it happens whenever I power on and/or reboot. Script fails as though it can't open anything. Running the script as root works like a champ. Am I mistaken in thinking that I can run any *.sh file in ~root in rc.local and it will be run as root (meaning no permission problems).
Line in /etc/rc.d/rc.local: /root/virus-scan.sh > /dev/null 2>&1
Summary of version in ~root/virus-scan.sh #!/bin/sh COMMON_DIRS="/home /tmp" # skipping all /bin /sbin et al for this test /usr/bin/clamscan -ri $COMMON_DIRS --log="/var/log/clamscan.log"
Contents of log show /home as "can't open" and certain files in /tmp as "Permission denied"
Searching the web found only one forum that had a "doesn't work in rc.local, works if run as root command shell" but there is no answer to it. All the other links show different rc.local problems such as "isn't being run" and I can verify that my rc.local is being run
I have a call to "freshclam -d -c 2 -l /var/log/clam-update.log" that is working (though I keep getting out-of-date notice followed by up-to-date output when actually checking --- I'm trying to sort this out on clamav / Fedora man pages)
Thanks in advance for any help (and let me know if I need to provide any more info) Paul
On 02Jul2011 20:40, Paul Allen Newell pnewell@cs.cmu.edu wrote: | I am trying to run clamav from rc.local so it happens whenever I power | on and/or reboot. Script fails as though it can't open anything. Running | the script as root works like a champ. Am I mistaken in thinking that I | can run any *.sh file in ~root in rc.local and it will be run as root | (meaning no permission problems).
That should be the case. (Of course, SELinux can break anything - if you run out of ideas you could turn it off to see if the behaviour changes.)
| Line in /etc/rc.d/rc.local: | /root/virus-scan.sh > /dev/null 2>&1
Throwing away the output will not help your diagnosis. Try this:
/root/virus-scan.sh >/root/rc-local-virus.out 2>/root/rc-local-virus.err
and see what shows up.
| Summary of version in ~root/virus-scan.sh | #!/bin/sh | COMMON_DIRS="/home /tmp" # skipping all /bin /sbin et al for this test | /usr/bin/clamscan -ri $COMMON_DIRS --log="/var/log/clamscan.log" | | Contents of log show /home as "can't open" and certain files in /tmp as | "Permission denied"
Weird.
Try putting some stuff at the start of virus-scan.sh:
set -x pwd id
You can then verify that it is running as root and where. The -x will let you check the command line of clamscan is correct.
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.
Cheers,
On 07/02/2011 09:45 PM, Cameron Simpson wrote:
That should be the case. (Of course, SELinux can break anything - if you run out of ideas you could turn it off to see if the behaviour changes.)
I've had experience with SELinux issues. There's something about the Einstein@home work units that keeps triggering them. Each time it happens, I get an alert. And, there was a time that SELinux kept getting triggered because of sloppy programming in GoogleEarth. In every case, I've gotten an alert and, if there was a way to correct it, instructions. I'm not sure how that works during startup, but there should be a log you can check. If there's nothing in the log, SELinux isn't an issue.
inline and at tail ...
On 7/2/2011 9:45 PM, Cameron Simpson wrote:
On 02Jul2011 20:40, Paul Allen Newellpnewell@cs.cmu.edu wrote: [...] Am I mistaken in thinking that I | can run any *.sh file in ~root in rc.local and it will be run as root | (meaning no permission problems).
That should be the case. (Of course, SELinux can break anything - if you run out of ideas you could turn it off to see if the behaviour changes.)
Will respond via Joe Zeff's email ...
| Line in /etc/rc.d/rc.local: | /root/virus-scan.sh> /dev/null 2>&1
Throwing away the output will not help your diagnosis. Try this:
/root/virus-scan.sh>/root/rc-local-virus.out 2>/root/rc-local-virus.err
and see what shows up.
See attachment for both *.out and *.err, plus the actual virus-scan.sh script and the rc.local file
| Summary of version in ~root/virus-scan.sh | #!/bin/sh | COMMON_DIRS="/home /tmp" # skipping all /bin /sbin et al for this test | /usr/bin/clamscan -ri $COMMON_DIRS --log="/var/log/clamscan.log" | | Contents of log show /home as "can't open" and certain files in /tmp as | "Permission denied"
Weird.
Try putting some stuff at the start of virus-scan.sh:
set -x pwd id
You can then verify that it is running as root and where. The -x will let you check the command line of clamscan is correct.
In *.out and *.err attachments
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.
Cheers,
Not certain about this last bit .. are your suggesting that I put the strace command in the rc.local? 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.
Thanks, Paul
On 7/2/2011 10:06 PM, Joe Zeff wrote:
On 07/02/2011 09:45 PM, Cameron Simpson wrote:
That should be the case. (Of course, SELinux can break anything - if you run out of ideas you could turn it off to see if the behaviour changes.)
I've had experience with SELinux issues. There's something about the Einstein@home work units that keeps triggering them. Each time it happens, I get an alert. And, there was a time that SELinux kept getting triggered because of sloppy programming in GoogleEarth. In every case, I've gotten an alert and, if there was a way to correct it, instructions. I'm not sure how that works during startup, but there should be a log you can check. If there's nothing in the log, SELinux isn't an issue.
Though I am just guessing, it seems that it is a permissions issue. If anyone can tell me where the SELinux log is or how to turn it off, I will gladly run tests with that
Thanks, Paul
On 02Jul2011 22:26, Paul Allen Newell pnewell@cs.cmu.edu wrote: | On 7/2/2011 10:06 PM, Joe Zeff wrote: | > On 07/02/2011 09:45 PM, Cameron Simpson wrote: | >> That should be the case. (Of course, SELinux can break anything - if you | >> run out of ideas you could turn it off to see if the behaviour changes.) | > I've had experience with SELinux issues. There's something about the | > Einstein@home work units that keeps triggering them. Each time it | > happens, I get an alert. And, there was a time that SELinux kept | > getting triggered because of sloppy programming in GoogleEarth. In | > every case, I've gotten an alert and, if there was a way to correct it, | > instructions. I'm not sure how that works during startup, but there | > should be a log you can check. If there's nothing in the log, SELinux | > isn't an issue. | | Though I am just guessing, it seems that it is a permissions issue. If | anyone can tell me where the SELinux log is or how to turn it off, I | will gladly run tests with that
You can put it into non-enforcing mode on the fly with the command:
setenforce 0
Run "setenforce 1" to turn it back on.
One of SELinux' many charms is that a program's ability to do stuff can depend on where it is invoked. I'm sure this is great for making fine grained controls, but it also makes for terrible debugging situations.
Responses to your other email in other reply.
Cheers,
On 02Jul2011 22:24, Paul Allen Newell pnewell@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 Newellpnewell@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@localhost paul@localhost | /usr/bin/clamscan -ri $COMMON_DIRS_1 --log="$CLAM_LOG" | mail -s virus-scan_1.`date +%d%b%y_%k%M` root@localhost paul@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@localhost paul@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@localhost paul@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@localhost paul@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@localhost paul@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@localhost paul@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,
On 7/3/2011 12:53 AM, Cameron Simpson wrote:
On 02Jul2011 22:26, Paul Allen Newellpnewell@cs.cmu.edu wrote: | On 7/2/2011 10:06 PM, Joe Zeff wrote: |> On 07/02/2011 09:45 PM, Cameron Simpson wrote: |>> That should be the case. (Of course, SELinux can break anything - if you
You can put it into non-enforcing mode on the fly with the command:
setenforce 0
Run "setenforce 1" to turn it back on.
I am presuming that I can put this in rc.local before the clamscan command as I need to make sure it is turned off before rc.local runs clamscan. Or, is there a better place to "setenforce 0" to disable (either so reboots come up off or before rc.local is called)?
I'm reading/learning/digesting/testing your other responses before replying
Thanks, Paul
On 7/3/2011 12:35 PM, Paul Allen Newell wrote:
On 7/3/2011 12:53 AM, Cameron Simpson wrote:
On 02Jul2011 22:26, Paul Allen Newellpnewell@cs.cmu.edu wrote: | On 7/2/2011 10:06 PM, Joe Zeff wrote: |> On 07/02/2011 09:45 PM, Cameron Simpson wrote: |>> That should be the case. (Of course, SELinux can break anything
- if you
You can put it into non-enforcing mode on the fly with the command:
setenforce 0
Run "setenforce 1" to turn it back on.
I am presuming that I can put this in rc.local before the clamscan command as I need to make sure it is turned off before rc.local runs clamscan. Or, is there a better place to "setenforce 0" to disable (either so reboots come up off or before rc.local is called)?
I'm reading/learning/digesting/testing your other responses before replying
Thanks, Paul
I see this is answered in your other email, so please ignore this question.
On 7/3/2011 12:53 AM, Cameron Simpson wrote:
On 02Jul2011 22:26, Paul Allen Newellpnewell@cs.cmu.edu wrote: | On 7/2/2011 10:06 PM, Joe Zeff wrote: |> On 07/02/2011 09:45 PM, Cameron Simpson wrote: |>> That should be the case. (Of course, SELinux can break anything - if you
You can put it into non-enforcing mode on the fly with the command:
setenforce 0
Run "setenforce 1" to turn it back on.
That seemed to do it ... wrapping the clamscan in setenforce=0 / setenforce=1 produced scans of all files and no errors. Many thanks for the advice on how to do.
Of course, your comment in other email about "if you can establish that disabling selinux makes it work", I sure got alot of barking from selinux and guess I need to learn all about rules for it.
Total of 355 errors regarding "read", "getattr", "search", "open", and "write". It appears that it is related to files/binaries/whatever in /bin, /sbin, and ~root (maybe /tmp?). I need to do some further debugging to confirm this (and to reduce the testing to something manageable)
The suggestions the pop-up gives me are for "allow this access for now" as opposed to something more permanent.
Before I go starting to learn about selinux rules, I wanted to check whether my sense that "if I do a setenforce=0 then I would expect selinux to be disabled until setenforce=1; hence, why does it need rules when disabled" is a proper way to look at it.
And, yes, my security stance is such that I don't mind a temporary disable while clamscan is running, I would rather not permanently disable selinux.
Thanks in advance, Paul
On Jul 3, 2011 5:38 PM, "Paul Allen Newell" pnewell@cs.cmu.edu wrote:
On 7/3/2011 12:53 AM, Cameron Simpson wrote:
On 02Jul2011 22:26, Paul Allen Newellpnewell@cs.cmu.edu wrote: | On 7/2/2011 10:06 PM, Joe Zeff wrote: |> On 07/02/2011 09:45 PM, Cameron Simpson wrote: |>> That should be the case. (Of course, SELinux can break anything -
if you
You can put it into non-enforcing mode on the fly with the command:
setenforce 0
Run "setenforce 1" to turn it back on.
That seemed to do it ... wrapping the clamscan in setenforce=0 / setenforce=1 produced scans of all files and no errors. Many thanks for the advice on how to do.
Of course, your comment in other email about "if you can establish that disabling selinux makes it work", I sure got alot of barking from selinux and guess I need to learn all about rules for it.
Total of 355 errors regarding "read", "getattr", "search", "open", and "write". It appears that it is related to files/binaries/whatever in /bin, /sbin, and ~root (maybe /tmp?). I need to do some further debugging to confirm this (and to reduce the testing to something manageable)
The suggestions the pop-up gives me are for "allow this access for now" as opposed to something more permanent.
Before I go starting to learn about selinux rules, I wanted to check whether my sense that "if I do a setenforce=0 then I would expect selinux to be disabled until setenforce=1; hence, why does it need rules when disabled" is a proper way to look at it.
And, yes, my security stance is such that I don't mind a temporary disable while clamscan is running, I would rather not permanently disable selinux.
Thanks in advance, Paul
it really is bad form to run a script out of root's home directory. Perhaps put it in /usr/sbin , restorecon, and leave selinux enforcing the whole time.
-paul
On 7/3/2011 2:54 PM, Paul Morgan wrote:
On Jul 3, 2011 5:38 PM, "Paul Allen Newell" <pnewell@cs.cmu.edu mailto:pnewell@cs.cmu.edu> wrote:
it really is bad form to run a script out of root's home directory. Perhaps put it in /usr/sbin , restorecon, and leave selinux enforcing the whole time.
-paul
Yeah, a reflection on such makes sense. I'll have to see if I still need setenforce=0 as I think the issue is rc.local executing the script and not where the script is (and I have no basis for that statement except for running the script as root directly works).
Lots more debugging and reading on my end to see whether this selinux issue is really it
Thanks for the advice on "good form" Paul
On 03Jul2011 15:02, Paul Allen Newell pnewell@cs.cmu.edu wrote: | On 7/3/2011 2:54 PM, Paul Morgan wrote: | >On Jul 3, 2011 5:38 PM, "Paul Allen Newell" <pnewell@cs.cmu.edu | >mailto:pnewell@cs.cmu.edu> wrote: | > | >it really is bad form to run a script out of root's home | >directory.
A little untidy, sure. But...
| Perhaps put it in /usr/sbin , restorecon, and leave | >selinux enforcing the whole time.
I wouldn't do this. /usr/sbin et al are the vendor's filesystem space; they're free to put anything there and you may end up conflicting.
Generally, ad hoc system owner scripts belong in /usr/local (usually /usr/local/bin for scripts/executables, or /usr/local/sbin for not-general-purpose-command executables), or in /opt/something, such as /opt/my-org-name/{bin,sbin,etc} as elsewhere, or in ~special_username/bin (for example, ~backup/bin for the backup scripts if you use the backup account for such stuff).
| Yeah, a reflection on such makes sense. I'll have to see if I still | need setenforce=0 as I think the issue is rc.local executing the | script and not where the script is (and I have no basis for that | statement except for running the script as root directly works).
Running it as root directly is post the login, which I think selinux endows with fewer constrictions. So it's not "where" so much as "when".
The problem with "setenforce 0" is that it doesn't just affect stuff you're running from that script, it affects the whole system - selinux stops preventing _everything_ it would normally have. OTOH, at rc.local time there's pretty much nothing else happening - all the system daemons are up but probably idle and the login prompts haven't yet issued. So timingwise it is a good time to temporarily disable selinux.
And regarding the "why does selinux log so much with setenforce 0": selinux isn't off, it is just in "permissive" mode - report all violations of the rules but don't prevent them. It is a debugging mode; the intent is that you correct your rules. You can also run the system with selinux genuinely off, though I think it may need a reboot once selinux has been started at all.
Cheers,
On 7/3/2011 5:15 PM, Cameron Simpson wrote:
On 03Jul2011 15:02, Paul Allen Newellpnewell@cs.cmu.edu wrote: | On 7/3/2011 2:54 PM, Paul Morgan wrote: |>On Jul 3, 2011 5:38 PM, "Paul Allen Newell"<pnewell@cs.cmu.edu |>mailto:pnewell@cs.cmu.edu> wrote: |> |>it really is bad form to run a script out of root's home |>directory.
A little untidy, sure. But...
[...]
And regarding the "why does selinux log so much with setenforce 0": selinux isn't off, it is just in "permissive" mode - report all violations of the rules but don't prevent them. It is a debugging mode; the intent is that you correct your rules. You can also run the system with selinux genuinely off, though I think it may need a reboot once selinux has been started at all.
Cheers,
Regarding where to put it, I was already thinking /usr/local/{bin,sbin}, just wanted to figure out whether bin or sbin was better (gut instinct would be bin)
I have managed to figure out that there is this mode known as "permissive" and that sure cleared up alot of my "on/off" assumptions.
I have been reading up about rules and audit2allow. Makes sense in theory, but when I looked at the rule that was generated with audit2allow, its 365 lines long. Plus trying multiple reboots gives me warnings about different files. When rebooting, I see 50 warnings; when I run as root, I see @270 warnings (only /home for reboot; all searched directories for running in terminal). The 365 is only for the 50 warning version ...
I can't see any way to temporarily disable selinux from catching violations while I do the clamscan (though the pop-up asks me if I want alerts, it doesn't look like getting an alert prevents the violation from being caught)
My first question is whether there is a way to go "allow clamscan_t * {read open search getattr}" so that clamscan will have permission to examine anything on the system (which is what I would want with a virus scan, right?). I discovered that the write warnings were for the debug writing to *.out and *.err per your suggestion, so I gratefully don't have to give clamscan write clearance.
The second question is why wouldn't selinux be defaulted to allow clamav given that's what Fedora seems to be suggesting/using? That being said, there is probably a good reason that I am not savvy enough to see ... but I still want to ask the question.
One good thing is I'm finally beginning to get an idea of what selinux is out of all this ...
Thanks, Paul
On 03Jul2011 17:35, Paul Allen Newell pnewell@cs.cmu.edu wrote: | On 7/3/2011 5:15 PM, Cameron Simpson wrote: | > On 03Jul2011 15:02, Paul Allen Newellpnewell@cs.cmu.edu wrote: | > | On 7/3/2011 2:54 PM, Paul Morgan wrote: | > |>it really is bad form to run a script out of root's home | > |>directory. | > | > A little untidy, sure. But... [...] | > | > And regarding the "why does selinux log so much with setenforce 0": | > selinux isn't off, it is just in "permissive" mode - report all | > violations of the rules but don't prevent them. It is a debugging mode; | > the intent is that you correct your rules. You can also run the system | > with selinux genuinely off, though I think it may need a reboot once | > selinux has been started at all. | | Regarding where to put it, I was already thinking /usr/local/{bin,sbin}, | just wanted to figure out whether bin or sbin was better (gut instinct | would be bin)
My habit for a virus scanner would be sbin; these days bin is for general purpose commands which sbin is for administrative commands (eg setenforce) and daemons (eg sshd).
In the distant past the "s" meant "standalone" or "static(ly-linked)"; things that would work before anything other than the (usually quite small) root filesystem was first mounted. So: core utilities needed for bootstrap (thus "standalone") and also this stuff needed to run before the shared libraries from /usr/lib were available (so "staticly linked" - the library code inbuilt to the executable); in those days /usr was normally a separate filesystem - indeed that's the whole reason we have both / (/bin, /sbin etc) and /usr (/usr/bin, /usr/sbin et al) - they were once separate filesystems.
Of course, the standalone meaning came first, predating shared library support...
| I have managed to figure out that there is this mode known as | "permissive" and that sure cleared up alot of my "on/off" assumptions.
Yah. See the file /etc/sysconfig/selinux on rehdat derived systems like Fedora (maybe "derived" should be "related" or "precursor" or "bleeding edge" here, but...)
| I have been reading up about rules and audit2allow. Makes sense in | theory, but when I looked at the rule that was generated with | audit2allow, its 365 lines long. Plus trying multiple reboots gives me | warnings about different files. When rebooting, I see 50 warnings; when | I run as root, I see @270 warnings (only /home for reboot; all searched | directories for running in terminal). The 365 is only for the 50 warning | version ...
I expect it varies depending on what clamscan thinks is needs to scan each time.
Do you run prelink? It hacks binaries about on a regular basis and may be causing clamscan to be more active.
| I can't see any way to temporarily disable selinux from catching | violations while I do the clamscan (though the pop-up asks me if I want | alerts, it doesn't look like getting an alert prevents the violation | from being caught) | | My first question is whether there is a way to go "allow clamscan_t * | {read open search getattr}" so that clamscan will have permission to | examine anything on the system (which is what I would want with a virus | scan, right?).
That's what I would look for. I am not an selinux guru and can't help you with the syntax there, but I would think you're on the right track with that rule.
| I discovered that the write warnings were for the debug | writing to *.out and *.err per your suggestion, so I gratefully don't | have to give clamscan write clearance.
Excellent, since it seems to use its own log file anyway.
| The second question is why wouldn't selinux be defaulted to allow clamav | given that's what Fedora seems to be suggesting/using?
Maybe it is, if it runs from /etc/init.d or something. Is clamav a fedora supplied package? If so, why is it run from rc.local instead of via a conventional presupplied chkconfig-controlled start/stop script?
Cheers,
inline and at tail ...
On 7/3/2011 6:22 PM, Cameron Simpson wrote:
On 03Jul2011 17:35, Paul Allen Newellpnewell@cs.cmu.edu wrote:
My habit for a virus scanner would be sbin; these days bin is for general purpose commands which sbin is for administrative commands (eg setenforce) and daemons (eg sshd).
[...]
Reading FHS 2.3 seems to consider bin "local binaries" and sbin "local system binaries". Going up to /usr/bin and /usr/sbin seems to be "primary" vs "non-essential" respectively. Given that it is embedded in rc.local, it doesn't seem non-essential as errors will occur if it not there. That being said, it sure looks academic so long as it is in /usr/local/{bin,sbin}.
[...]
| I have been reading up about rules and audit2allow. | [...] |
I expect it varies depending on what clamscan thinks is needs to scan each time.
Do you run prelink? It hacks binaries about on a regular basis and may be causing clamscan to be more active.
If I am running prelink, I don't know it. Your "varies" comment makes sense and I am not paying too much attention to it right now
| [...] | | My first question is whether there is a way to go "allow clamscan_t * | {read open search getattr}" so that clamscan will have permission to | examine anything on the system (which is what I would want with a virus | scan, right?).
That's what I would look for. I am not an selinux guru and can't help you with the syntax there, but I would think you're on the right track with that rule.
Making sure I am correct that it will understand "clamscan_t" and the wild card are not showing up in the docs from selinuxpolicy.org and I ain't seeing anything in related links when googling. I'll give it another round before posting a new thread explicitly on that with the hopes that some selinux gurus see. You certainly know enough to have gotten me to the point of "something working" ... many thanks !!!
[...]
| The second question is why wouldn't selinux be defaulted to allow clamav | given that's what Fedora seems to be suggesting/using?
Maybe it is, if it runs from /etc/init.d or something. Is clamav a fedora supplied package? If so, why is it run from rc.local instead of via a conventional presupplied chkconfig-controlled start/stop script?
It isn't part of the default "fresh" install, so I have to yum install it after. I remember seeing a Fedora draft doc talking about security and clamav, implying that it made sense to incorporate clamav into Fedora, but I can't find it now. The best I can spot is a reference to it in https://fedoraproject.org/wiki/SecurityBasics that says its in Fedora Extras. My goal is to get email up and running (rather than relying on Windows) and I wanted to try to sort out best defense available that meshed with Fedora.
The choice of rc.local is mine as I want it to happen at least once per time I use this F14 computer and don't want to have to su to root and manually run each time.
I've seen mention of chkconfig but know nothing about it ... and haven't been able to see any reason why rc.local isn't a reasonable choice for doing freshclam and clamscan
Once again, your help is very appreciated. I think I am actually up-and-running and just need to figure out how to do it cleaner.
Paul
On 03Jul2011 19:00, Paul Allen Newell pnewell@cs.cmu.edu wrote: | > I expect it varies depending on what clamscan thinks is needs to scan | > each time. | > Do you run prelink? It hacks binaries about on a regular basis and may | > be causing clamscan to be more active. | | If I am running prelink, I don't know it. | Your "varies" comment makes | sense and I am not paying too much attention to it right now
Try saying:
rpm -q prelink
If it is installed (it is by default on RH) it has a daily crontab entry; it used to trip our integrity checker regularly as binaries changed. That said, I think it should only muck things about if libraries get updated.
| > | The second question is why wouldn't selinux be defaulted to allow clamav | > | given that's what Fedora seems to be suggesting/using? | > | > Maybe it is, if it runs from /etc/init.d or something. Is clamav a | > fedora supplied package? If so, why is it run from rc.local instead of | > via a conventional presupplied chkconfig-controlled start/stop script? | > | It isn't part of the default "fresh" install, so I have to yum install | it after. [...]
It's still Fedora supplied if you don't need an extra repository to obtain it.
| The choice of rc.local is mine as I want it to happen at least once per | time I use this F14 computer and don't want to have to su to root and | manually run each time. | | I've seen mention of chkconfig but know nothing about it ... and haven't | been able to see any reason why rc.local isn't a reasonable choice for | doing freshclam and clamscan
rc.local is only a problem because of the selinux difficulties you're having.
Regarding chkconfig, it's a tool to control which start/stop scripts get run at different run levels, and therefor at boot.
Try this:
chkconfig --list
Does clamav show in the list?
A normal Fedora boot goes to runlevel 3 (text mode login) or 5 (GUI login). So if you want clamav to run at boot, chkconfig should show it as "on" for runlevels 3 and/or 5, usually both. Ths command:
chkconfig --level 35 clamav on
would do this (presuming "clamav" to be the relevant name listed by "chkconfig --list" above - adjust to suit).
of course, it would still be useful to figure out the best selinux incantation required to allow rc.local invocation of clamav...
Cheers,
I've been able to figure out that running clamscan from cron.d works with SELinux but rc.local doesn't and one has to use setenforce. I managed to get enough material together to submit Bug #720223 as that just doesn't seem right.
My system now does update and scan on reboot and then cron jobs to periodically run both if my machine is up for a good while (still sorting out good settings for "when")
I dug into SELinux and decided that it is a bit more than I am prepared to experiment with. I get the general idea behind it, but the policy rules are a bit much for a non-sysAdmin sort (and I don't want to run audit2allow as a "catch-all" when the files that will be barking are going to multiple over time, leading to patches on patches on patches).
I also filed a "sug" that clamscan should have a "test error" flag so one can see what happens when it really finds something. Plus a grumble that I found documentation lacking and almost everything I could get was from the web from prior releases (f11, f8 or f9) and not a maintained site.
I wanted to thank everyone for their help as I did learn alot out of this exercise (and hopefully more if I get an answer on my rc.local bug submission), Paul
-
Cameron Simpson -
Joe Zeff -
Paul Allen Newell -
Paul Morgan