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/ On Thu, Jul 28, 2016 at 1:13 PM, G.W. Haywood <cla...@jubileegroup.co.uk> wrote: > 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 > _______________________________________________ Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
