Thank you very much for the very thorough response.
Lots of helpful info.
The link you provided was very helpful.
There was a post to this link that I was able to use to get CalmAV working.
https://www.adminsys.ch/2015/08/21/installing-clamav-epel-centosred-hat-7-nightmare/
Post by G.W. HaywoodHi there,
Sorry I'm a total newbie ...
You said. Don't be sorry, we were all there at one time or another.
To be honest sometimes I wish I was back there, but that's well OT. :)
... attempting to install ClamAV version 0.99.2 onto a CentOS 7 ...
Have you seen anything like this?
https://linux-audit.com/install-clamav-on-centos-7-using-freshclam/
The system will mostly be used by multiple users for internet,
Post by Freddy Allenemail, and word processing. Maybe games too.
That doesn't quite tell us all we need. Can we take it that the email
service will be hosted on some third party server somewhere like gmail?
The reason for the question is that many of us use ClamAV primarily on
mail servers to scan mail as it passes through the MTAs (Mail Transfer
Agent) running on the mail servers, and not to scan files on disc (or
whatever passes for disc thesedays). You can have a 'daemon' running
on any server, which will listen for data which comes to it down some
sort of pipe and scan it. Or it can listen for paths in a filesystem
of what for now I'll call files, and scan them if it can access them.
Or you can start a proccess and tell it 'go scan this lot'. These
different ways of doing things are all possible with ClamAV. To me,
it doesn't sound like you'll be hosting a mail server anytime soon,
and you'll probably be in the 'go scan this lot' camp.
My confusion starts with ... installing on a 'shell account'. It
Post by Freddy Allenmentions an assumption of home directory '/home/gary'. That makes
me think that particular installation method would only be for a
system with one user account (in their example 'gary').
Not at all. There are essentially two kinds of user account on your
Operating System (OS). The two are 'privileged' and 'not privileged'.
It is normal procedure on such systems to BUILD software from source
using any 'not privileged' account and then to INSTALL the resulting
code (binaries, configuration files etc.) using a privileged account.
You are installing onto the system, not onto any particular account.
The code BUILD process is done using storage allocated to some random
user such as 'gary' in your example and then 'root' (privileged user)
will INSTALL it into system areas. The 'root' user will then likely
also RUN the software if it needs to access things which gary can't.
So for example root might start a daemon which can read any file on
the system, and the daemon might then be told by another user (which
has limited filesystem access) to scan the entire filesystem. Or a
privileged process might hand data to an unprivileged daemon so that
the daemon can scan it, even though the daemon can't directly access
the data being scanned.
Incidentally it's also normal procedure to USE the system for almost
everything you do (Web browsing, email, word processing, games...) as
a 'not privileged' user, which all your five user accounts should be.
... the last line ends with 'Don't forget to lock access to the
Post by Freddy Allenaccount!' then provides no assistance as to how ...
A system might also want to run some processes which don't need to
have privileged system access. In that case it's common to create
a user specifically for this purpose, such as the 'clamav' user in
this case. One would normally not permit this what-you-might-call
dummy user to have a login shell or password. That's usually done
at the point of creation of the user account, by running a script
provided by your OS distribution such as 'adduser' which interacts
with you while you create the user account and asks things like if
the account should have a login shell. Anyway, locking access to
the account would generally mean not giving the account a shell in
(probably) /etc/password or a password in (probably) /etc/shadow.
That's right, passwords aren't stored in /etc/password. History. :)
The clamav user can have a /home/ directory where stuff is stored
that may be interesting or not, depending on your point of view.
However if you use 'packages' which are provided by your distribution,
I would expect all of this to be taken care of for you when you simply
install the package(s) provided.
If I install on a shell account, will the software ...
You aren't installing "on a shell account".
A shell is a tool. There are several in common use, like 'bash' which
I use all the time and 'tcsh' (which my wife favours, bless her). You
should avoid 'gnash' like the plague, but I digress.
When I log in, I like to see a prompt from a shell on the screen and
nothing else. Younger people seem to prefer to see some sort of
graphical thing. It's up to you but both of these scenarios are of
users logging into computers to do stuff. Both can run a shell if
they so desire, the younger person will probably do so in an 'xterm'.
I usually have a few shells running at any one time, and I'd be lost
without them. A lot of people don't run a shell from one week to the
next, perhaps only to do './configure ; make ; su - ; make install'
which are broadly speaking the four steps to build and install almost
anything from source on a Unix/Linux/BSD or similiar system. But if
they want to they can all fire up a shell when they feel the need.
If not, and I need to install as a new clamav user, how do I
Post by Freddy Allensecurely set that up?
You'd be better off using packages from your distribution if they
exist for whatever you want to do. You clearly aren't yet in a
position to make informed choices and securely set up a server,
and it's quite a long and somewhat tedious learning process to
get there - assuming it's even possible! To begin with you could
perhaps do worse than find a couple of beginner guides to Unix or
similar operating systems which will deal with accounts generally,
filesystems, their organization, processes, ... it's a long list.
Above all else I recommend that you don't lose any sleep over this.
Although it's possible to compromise almost any computer system, you
don't have to worry about viruses attacking CentOS like you do with,
er, some operating systems I could mention. You _do_ have to worry
about getting something from a compromised computer and then passing
a copy of it to someone who is using a vulnerable computer - even if
your computer isn't vulnerable - but that's pretty unlikely if you
behave sensibly.
--
73,
Ged.
_______________________________________________
https://github.com/vrtadmin/clamav-faq
http://www.clamav.net/contact.html#ml