steve(a)silug.org (Steven Pritchard) writes:
> > Besides, in this case, all you need to do is let clamd run
as its
> > own user, with a writable socket file.
>
> Writable for whom? For 'clamd' only would not make sense, world-writable
> is a huge security risk: user A could gain information about user B by
> scanning his files.
How? If the (unprivileged) clamd user can read user B's files, then
user A could just read them with cat. If clamd has any special
privileges, then it isn't configured properly.
Ok, user A gets mail and want it to be checked. There are two ways for
that:
* mail is at an public place so that clamd can access it -> bad, I do
not want my mails at public places
* mail will be placed at a place accessibly for clamd and A only -> how
can I do this without ACL's? Besiding this, it would be still possibly
for B to gain information about A's mail by invoking clamd to read it.
> DOS attacks are possible also: users should not be
> able to shutdown system services with a simple 'QUIT' command.
If clamd allows that, it's a bug and should be fixed.
Page 3 in clamdoc.pdf:
| * QUIT
| Perform a clean exit.
In my amavisd package, I just make the temporary path executable by
clamd's group, so it can open files when it is given a path BUT THAT'S
IT. The only problem that arises is if the end-user wants to install
other virus scanners and do the same thing with them, but that's their
problem to solve, not mine. :-)
Arises within other situations also. E.g. with spamblockers or webaccess to
the quarantine area. Results in endless, non-auditable bunch of directories
which breaks on minimal modifications.
I totally disagree. This is no different than random users wanting
to
allow access to something from apache but nothing else...
This requires that ~/public_html is accessible for httpd. In non-ACL
capable systems this means world-access and I would never do this for my
mails.
Enrico