A quick note on Passwords.

I was having a discussion with my father over the phone this morning attempting to help him along with a problem he was having with his e-mail. We sorted the problem out and he asked how he could go about changing his password. I tried explaining it to him but it was easier for me to just do it so I asked him what his current password was and what he wanted his new password to be. His current password, he relayed to me, was "aaaaaaaa".... 8 a's because he has to use at least 8 characters. It would take a dictionary about a second to crack that password, presumably on it's 8th attempt assuming that the wordlist/dictionary being used started at "a" or "A" instead of "0". In either case it wouldn't take that long at all.

So this made me think, what does a strong password mean? By some definitions it means "having an entropy of 128 bits or more" which means  that the password generation scheme which you used may generate at least 2¹²⁸ other distinct passwords.  So we are not talking about 8 or 10 characters, rather 20 completely random characters, or a list of 10 randomly chosen "common words". My personal passwords are usually 12-16 characters made up of symbols, numbers and letters in an order that makes sense to me, or for sites I access a lot and don't require a stronger password I use a passphrase. It is easier to remember "thisISaBLOGentry123456" or whatever (obviously that one is easy, it's just an example) than a clusterfuck of symbols, letters and numbers which mean nothing to you. These random character generates can sometimes make things worse off especially if you want other people, such as workers, to use this these random generated passwords, with for example 16 characters, spitting out something like "6Iuh%jkl00aS2HHt". I can almost promise you that your employee will either write that down on a post-it note and stick it somewhere in there office/cubicle/whatever or keep a note of it somewhere like their wallet or purse. The great random, 16 character password you thought was so secure just became pointless.

Just my thought for the morning.

Restrictions: Compilers

Compilers and other developmental tools are both valuable and convenient to have on your system, and for some people they are a necessity. Most people suggest removing these compilers and specific "Language Development" tools simply because once an attacker has access to these things it only makes it easier for him to escalate privileges, write tools directly on your box, and then use your own compiler to compile them (there have been a good number of rootkits requiring the attacker compile them on your system). Removing them is a great idea in a lot of circumstances, and sometimes not. I personally have never removed my compilers and certain development tools, but rather I restricted access to them by using "permissions".

First things first, you need to query each individual package to see the binaries which they contain. And please don't assume that you know where they all are, or what binaries are used by different tools and packages, just take that extra time to query these, then restrict access and permission to those specific binaries:

codecult# rpm -q --filesbypkg gcc | grep 'bin'   

  gcc                                     /usr/bin/cc

  gcc                                    /usr/bin/gcc

  gcc                                   /usr/bin/gcov

..and so on. Using your package manager (rpm in this instance) I looked up files provided by gcc as well as using grep to report back only those files which are contained in binaries directory such as /bin, /usr/bin, etc. Now that you know where these are located you will want to create a special group that has been granted access to these compiler binaries by using the groupadd command. In my case...

codecult# groupadd gccgroup

 

After this step is finished it is time to go about changing ownership of those binary files you want to restrict. In my example I am changing them to group I just create, gccgroup by doing the following:

codecult# chown root:gccgroup /usr/bin/gcc

Lastly you must change its permissions to be executable by the root user members of that "compiler group", if anyone outside of the permitted users attempt access to the gcc-compiler they will be be denied permission. In order to change those permissions to be executable only by the root user of this gccgroup group I used the following:

  codecult# chmod 0750 /usr/bin/gcc