The don't waste your money on AV software for Linux thread

[Void Main]

WOW! Thats a lot of stuff I wasn't aware of VoidMain...Guess these Official RedHat are totally useless..Coming back to the point, from what I understood so far, (pls correct me if I'm wrong)

1) The consolehelper is used to authenticate root users via the GUI

2) SU is used to authenticate root users via a terminal, command prompt.

Not quite. Anything you set up via console helper will always run as root. If you already are root it will not prompt you for a password. If you are not root it will ask you for roots password. If you correctly enter the password the app will run, if you do not enter the password it will not run. It works in or out of Xwindows automatically.

"su" is optionally used to get a root shell or run a program as root. e.g. "su -" by itself will open a root shell. Anything you run from that shell will be run as root. "su - -c progname" will just run a specific program as root. Actually you can use the "su" command to become any logon user you wish but people commonly use it to do root tasks from a normal user session.

"sudo" is sort of like "su" except you configure it to run specific apps and when configured will not prompt for a password. You can specify which users have authority to run which commands as root.

Also, how can the password for certain progs like KPP be disabled alltogether via consolehelper?

I assume you mean can you run kppp without asking for the root password. The reason kppp asks you for root's password if you are not already root is because it is already configured and run as a consolehelper app. I am going to assume that you want to get rid of the password because you want to allow other people that use your machine to dialup without giving them the root password. Personally, if it were only me using the system I would leave it to prompt for root's password before allowing kppp to run. It's one of those minor inconveniences that add security. At any rate, to answer your question there are several ways you can do this.

One way of doing it is to edit /etc/pam.d/kppp and change this line:

Code: Select all

auth    sufficient      pam_rootok.so


to

Code: Select all

auth    sufficient      pam_permit.so


The above is probably the easiest. Keep in mind that for each thing you do this for you are making your system just a little bit more vulnerable. Having to type in passwords usually is not a bad thing.

A second way is you could set it up as a sudo app so you would then run it as "sudo kppp" and it wouldn't ask for a password. You do this by configuring the /etc/sudoers file. Specifically add a line that looks like this to the end of /etc/sudoers:

Code: Select all

agent007 ALL=NOPASSWD: /usr/bin/kppp


Change "agent007" to whatever username you use to log in to your system with. Note that the sudoers file is only readable by root and does not have the write bit set so when I edit the file with "vim" I save it by using the ":w!" command which overrides not having the write bit set. Then when you run kppp do it like this "sudo kppp" which will not prompt you for a password. Of course you would have to change your menu/icon items to reflect this. Alternately you could replace the /usr/bin/kppp link with a little script that calls "sudo /usr/sbin/kppp" so you don't have to change your menu/icons.

A third way is to reconfigure it not to be a consolehelper app and set the SUID bit on it. You should note that /usr/bin/kppp is just a link to /usr/bin/consolehelper. The "real" kppp is in /usr/sbin. You could remove the link to consolehelper and link it directly to "/usr/sbin/kppp" and then set the SUID bit on it:

$ su -
# cd /usr/bin
# rm kppp
# ln -s /usr/sbin/kppp kppp
# chmod u+s /usr/sbin/kppp

Now it should run as root without prompting for a password. However, the above method is the absolute worst way you can do it. There are very few programs on your system that are designed to run with the SUID bit set in their permissions, and they are heavily scrutinized for security because of this. The first way is the easiest, the second way is the most secure (next to actually requiring a password) and the third way is the worst way.

[edit]
Just ran across a doc on Red Hat's site covering consolehelper.
[/edit]

[agent007]

VoidMain, You have guessed my questions absolutely right! Don't have anything more to ask....The explanation was really neat and to the point. Wish we had a guy like u to teach at college..

thanks a tonne,
007

PS: Have u ever considered writing a book?

[agent007]

Hi VoidMain,

Continuing ur discussion, from

http://arstechnica.infopop.net/OpenTopi ... 4680976855

What if?

1) Apache is exploited and root access is gained
2) Root-kit is installed & there is NO security scanner to scan for root-kits
3) A virus is installed and the payload is set to go off at a later date (logic-bomb).
4) The admin is unaware of all this and thinks that everything is safe..

Since the admin is unaware of points 1&2, then a virus scanner would be his only best bet to save the system. Ofcouse the alert would have to go off immediately after point 3..

These admins around here know nothing much of administering GNU/Linux and Unix systems. That is why I thought of the diff scenarios wherein a virus scanner would come in handy (for unaware admins ofcourse). what say?

rgds,
007

[Void Main]

VoidMain, You have guessed my questions absolutely right! Don't have anything more to ask....The explanation was really neat and to the point. Wish we had a guy like u to teach at college..

I'm available. :)

PS: Have u ever considered writing a book?

I've considered it but I am much too lazy and what do I know about writing a book anyway? Besides, I'm not a known expert in anything, usually people who write books have all sorts of credentials. I wish I weren't so lazy. :)

[Void Main]

Hi VoidMain,
What if?

1) Apache is exploited and root access is gained
2) Root-kit is installed & there is NO security scanner to scan for root-kits
3) A virus is installed and the payload is set to go off at a later date (logic-bomb).
4) The admin is unaware of all this and thinks that everything is safe..

Since the admin is unaware of points 1&2, then a virus scanner would be his only best bet to save the system. Ofcouse the alert would have to go off immediately after point 3..

These admins around here know nothing much of administering GNU/Linux and Unix systems. That is why I thought of the diff scenarios wherein a virus scanner would come in handy (for unaware admins ofcourse). what say?

If a 5kr1pt kiddie root's your system then you already have a much bigger problem than a virus. Your system is only likely to be exploited if it is not kept up to date and you don't follow good (even basic) security practices. It is far more important to keep your system updated with all of the security updates. Everyone should be signed up for the CERT mailing list. It will tell you when vulnerabilities are known, how to fix them before they can be exploited.

It is no harder (in fact it is easier) to make sure your system is up to date than it is to install virus software and keep it up to date, and it doesn't cost you anything. Also the CERT mailing list will tell you when a script kiddie has beaten the security updates and tell you how to check for a break-in. This *usually* doesn't happen. The vast majority of the time there is a security fix for vulnerabilities before there is a known exploit. The only people who are exploited are those that do not keep up on updates. And if you follow good security practices usually even if you have a vulnerability there is a good chance that it will not be exploited (firewall, only allow access to those who need it and only from places where those people may reside).

It amazes me that people in the Windows world will spend all this money on virus software and keep it up to date, yet they fail to follow basic security practices. A new virus comes out and they still get hit, they run around like chickens with their heads cut off until McAffee, NAI, etc come out with an update and a cleanup strategy. The expend *many* man hours fixing, cleaning, repairing, when they might not have gotten the virus in the first place if they would have followed basic security practices. And what good was the virus software when it didn't catch the virus? Sure, once the virus is known and they update the *.dat file the virus can't hit them again but that is "reaction" rather than "prevention", the damage is already done.

For instance, there is this company that I have done much work for recently. Originally they were a 100% Windows shop. They were hit with every new virus as soon as it came out. Every time their entire IT shop wasted at least a day going around cleaning up the mess not to mention the rest of the organization not being able to work. They run MS Exchange as their mail server and they have the latest virus software running on it. In fact they even have virus software built to run on the Excahnge server. They finally got tired of this and asked for help and we sat down and talked about it. I ended up installing two Linux machines in their DMZ to act as incoming mail and DNS servers for their organization. These machines basically just forward mail on to the exchange server which is inside their firewall.

The advantage is I could run "milter" filter applications in Sendmail on these Linux boxes and filter out unwanted attachments before they get to the Exchange server. All messages containing executable attachments (*.exe, *.com, *.bat, *.vbs, *.svr, etc, etc, etc, etc) are rejected and never make it to the Exchange server.

They have not had a virus that I am aware of since we put them in and that's been a few years now. Prior to installing these two servers (actually old discarded desktop machines) the Exchange server's CPU was overloaded scanning every incoming message for viruses. It would grind to a halt when a new virus came in that it didn't know about (I-LOVE-YOU, Mellisa, etc) because of the zillions of messages generated by the users who executed the virus. How much did this cost them? The hardware didn't cost them anything because they were just going to throw it out. The software didn't cost them anything, it's non-commercial open source software. The only thing it cost them was my time to set it up (I think I charged them for about 8 hours work, which was probably overkill). How much money have they saved since installing this? Hard to tell, but my guess is "boat loads".

I would suggest that if you want to run something, instead of running virus software you should configure tripwire. This will notify you if anything critical has changed that shouldn't have. At minimum have it set up to watch /bin,/usr/bin,/sbin,/usr/sbin,/usr/local/bin (anything in any user's PATH). Remember, virus software can only stop viruses that it knows about. If someone writes a new virus that the virus software does not know about, combines it with a network worm that exploits known vulnerabilities in apache then virus software isn't going to stop it. And what's the point in installing a virus when you already have root and can do whatever you want?

Another thing is, people don't pass pretty little executable programs around in *NIX like they do in the Windows world (*.scr, *.exe, etc) so the chances of the virus spreading from a vulnerable web server to anything else is slim. In the Windows world all it takes is a crafty email message and most of the Windows world is screwed. A crafty email message can not screw the *NIX world because *NIX users do not have write access to executable files.