[clamav-users] Newbie ClamAV install
discreteidentity at gmail.com
Tue Aug 2 10:24:49 EDT 2016
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.
On Thu, Jul 28, 2016 at 1:13 PM, G.W. Haywood <clamav at jubileegroup.co.uk>
> 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?
> 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.
> Help us build a comprehensive ClamAV guide:
More information about the clamav-users