Hi there, On Thu, 28 Jul 2016, Freddy Allen wrote:
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, email, 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 mentions 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 account!' 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 securely 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. _______________________________________________ Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
