[clamav-users] Newbie ClamAV install

Freddy Allen 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.

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 <clamav at 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
>



More information about the clamav-users mailing list