Discussion on how to secure SL

Although I firmly believe sudo to be not my friend, I would like to say thanks for this fine piece of work


Mod's edit: this discussion started with a great item on how to secure SL.

I agree, having sudo will much more likely make your system vulnerable (by having a not well thought out /etc/sudoers that inadvertently gives too many rights to too many people) than being useful to keep your system safe.

On a personal system sudo is almost always useless and only a potential security risk.

sudo can make sense on company servers where several people need privileged access, but shouldn't get the root password.

So unless you know what your are doing and have a specific need for sudo and are familiar with how to configure /etc/sudoers correctly, you should remove sudo from your system.

I disagree, I shall explain why. Okay first on a security point of view as this is what this is about really. You open an terminal and then:

1) You walk away from your computer a second; you have left a root to your machine unattended. Serious mistake

2) You have a root terminal open as you have done something that needed it and then you continue to use it from conviniance

3) You are root, unlike sudo commands are unable to be limited you are ether god or limited (root or normal user), sudo allows you to regulate what runs by which users.

Okay so we have these three problems, by the most part they can be avoided however we all know in everyday situations that simply isn't the case. The amount of times i go to grab a coffee or get called away to do sometihng and that little root terminal is behind some window or minimised and I have forgotten to close it, I occasionly catch me leaving the house without closing it! I'm not even in close proximity let alone not at my computer.

Now looking at sudo, I did in the tutorial go over the sudoers file, granted i didn't touch on it in much depth but i explained how you should limit it, how you can command limit it and the fact its imperative you do this!

sudo is a pain and thats why i occasionly find my self suing to root and i expose myself to the faults of humankind (me). Running sudo not only allows me to restrict root more easily but it means i tend to only use it when i need, i only sudo commands which actually need the elivated privalages.

So while you have some points, removing sudo due to lazyness of configuration isn't really worth dealing with because you have to make the effort to stay secure, to remember complex passwords, to setup ssh correctly, etc.. its just the same with ssh as sudo, you have to configure it correctly or you leave your self open to a hole host of attacks so really. Administrators should take the time and configure sudo correctly, after all, it takes the best part of 5 mins.

Leaving a root shell open at home is hardly a practical security risk.

like I said, if you know how to configure /etc/sudoers, then sudo can be useful.

But most people don't have a clue how to configure /etc/sudoers (or at most know a little and therefore configure it incorrectly/unsafely) and can't be bothered to learn how to configure it correctly since it's actually quite complex and not very intuitive to configure.

So on the average users' personal PC, sudo is just an additional vulnerability waiting to be exploited.

Ah, no that was an example however lets assume that you will as its what i do indeed use. Okay lets imagine i want to update so

[Jessica@localhost ~]$ sudo yum update
[sudo] password for Jessica:
<blah it updates>
[Jessica@localhost ~]$


Now it leaves me at a prompt which is limited privolages, so I'm there making my coffee and lets say my dad wants to cripple my machine for example, I don't know why but he wants to run malicous code and needs root to do so. So he has su or sudo to get root however both require a password. Now sudo does have a limited amount of time it remembers your authenticated for 5 mins i think it defaults too so if he's lucky he can sneek on in that time and yes, yes he will have root however. I did in my post suggest you alter the sudoer file and in my followup post i again reiterated it even clearer. So yes this was suppose to just give people an idea of what to do and i didn't go over everything in huge amounts of depth but putting this line in:

Defaults timestamp_timeout=0

will globally for all users never remember the password so this 5 minuit period can't be exploited

For those who want to go beyond Jessica's suggestions, and really lock down their system, I can highly recommend the NSA's Guide to the Secure Configuration of RHEL 5 available from this link:

NSA Configuration Guidance for Operating Systems

Whilst there is not yet an equivalent guide for RHEL6, much of the information remains relevant. The NSA also provides guides for other OS's as you can see at the above link, as well as wide range of guides elsewhere on their site.

I've used the RHEL5 guide a few times now to secure servers and a couple of important workstations.

NIST also produces some very useful guides and evaluations:

NIST CSRC Special Publications

... and a more general link:

NIST CSRC Publications

su -c "yum update" There is no timeout on that is there ?

I'm not a fan of sudo. I think it's a bad habit to get into. The majority of *NIX sysadmins will agree that using su like a man is a lot better. It makes you think more about what you're doing etc.

I took some things from the NSA guide (not all) urm its a very good publication and even they suggest sudo is used. I think su -c is fine i suppose depending on your situation, if you're the only person who uses the machine or the only person who you would give root to then yes, i can't see a problem however if you want to deligate certain privolages out its pretty much impossible without giving them full root if you're not going to give out selective commands i don't see a problem.

I wouldn't say sudo gets you into bad habbets inface i find my self when using su doing non root things in this root terminal simply because its there i could type exit but why bother when i will need it again in a sec maybe others have self restraint im not sure however i don't think sudo is a bad habbit at all you have to make the effort to sudo and then type your password and stuff every time you run a root command so its not quite like you're going to use it all the time, you use it when its needed.

It's frowned upon in the enterprise arena. For home users yeah sure but it's a no no in the corporate workspace.

let the folk frown?

I'm not a sysadmin, I'm a programmer so really i don't care xD sudo in my opinion reduces the posibility of security problems even in the rare unlikely cases so as far as I'm concerned i think its a good thing for people to use however by default i always think sudo is setup wrong.

Well that's the difference between coders and sysadmins I guess lol. It's too big of a risk on servers.

I run servers with sudo on, i think sudo is safer.

One thing that I use is Selinux Sandbox:

yum install policycoreutils-sandbox

in terminal:

sandbox -X -t sandbox_web_t firefox

This will start firefox sandboxed from the system with a proper X session and limited to the port 80 if I remember right. You can define new /home and /tmp folders if you want. Think can be tuned to pidgin too, but I never tried.

Sudo or no sudo (user can decide), this was a great thread/contribution Jessica...thanks!

How many users on your servers that you run sudo on? I'm talking about large enterprise environments. I'm not against the use of sudo, I have used it my self on servers at home.

The main reason it is deemed a security risk is unfortunately it's the same password as their user account. Sudo is very safe if people don't use the same password for everything but I've seen what happens when they do, it's not pretty.

I like that extra layer of security, but that's my job so I have to be pedantic about this sort of thing.

Agreed

Thanks for your reply, they are appriciated. I love this Selinux sandbox idea, great to isolate programs which connect to the internet which would usually pose extra attack vectors. I would love to see more on this and maybe configuring it. It sounds like something more people should know about (including me).

This is wonderful, thank you! I love all your security related posts...

@ Jessica_Lily

Just loved it too. I'm used to use this type of isolation on windows, where I not rely on blacklist software (aka Antivirus). I just use some Group policy controlling rights and execution, and on top a layer of isolation with a software called Sandboxie (there is Defensewall, Geswall and Bufferzone too) - applying isolation by policies/virtualization.

I know in Linux this type of thing is not necessary, but I get so used to it that started to look around. I'm using this one just because it's integrated in selinux, which is integrated in the system. Problem is that not exist to much information about... and the little I found sometimes is not common-human-readable

I give wrong information so I will try to correct. For the little I observed:

Look like the "sandbox_web_t" option not restrict access only to port 80. I tried and firefox sucessfully connected to https and ftp... so looks like pidgin can be used without problems. If this option it's not used, the confined executable cannot connect to internet.

I don't know the difference about "sandbox_web_t" and "sandbox_net_t".

Other than the information displayed in "sandbox --help"... the others options are mistery.

It's nice but sandbox is overkill for simple home user like me.

Anyway to save downloads: ( Thanks to Dan Walsh )

mkdir /tmp/myweb ~/myweb
sandbox -X -T /tmp/myweb -H ~/myweb -t sandbox_web_t firefox

Then you can download any content, setup bookmarks ... and the sandbox will not remove them when you are done. If you later run a command with the same sandbox homedir and tmpdir, the content will be there.
Works a treat !

Yes works great!

Just a note:

If you do not use the -X option, you need use -M option to be able to mount the custom /home and /tmp folders.

Remembering too that how the content is isolated from the OS (even a ctrl-c/ctrl-v to copy a link location not work) you can use the -i (single file) or -I (list of files) to include files in the sandbox.


Will see if I encounter time to test the -S option:

[EDIT]

Hi all,
Played 10 minutes with it... so far is simple to use.. just a little detail:
You must specify a Homedir and tempdir when setting up a session sandbox

Received some alerts/errors. Not tried execute things that require root access, like change system settings and things like that but "yum search" worked. Firefox in the first time started and connected ok, after issuing the command again it give a error. Pidgin started without errors, but I not logged.
Look like there is no need to specify the sandbox_web_t to have access to internet.
If actions that require root privileges like system-wide changes/ Software installations works ok in this sandboxed session, can be used like a test plataform.

@s23

Are you using the -w flag to resize the window ? I haven't tried it yet as there are apparently some limitations there.
The -i flag is great but watch those passwords

@ all - nice discussion, some good insights i learned something new.

As for the discussed /etc/sudoers - it depends, for me it is situational use. Ofc, i'm stubborn to grant any access to anyone on the server/s ... :-).
But lets say some application guys need to access to application user and / or need to check some application logs, cat files etc. - in such case the 'sudo' command is handy.

Basically, i use common sense and approach 'deny all' first and then lets see who complains (doesnt matter if service or user) and then allow some necessary. ...

+1

Giving something is always easier than taking something away.

For what I see when I tried, using when sandboxing applications just start the window at the designed size, not change the resolution (and looks like it only accept in the format 800x600... format like 0x317 not work). It change/limit the resolution when using for sandbox a session.

This is what i use. Whitelist is the way to go.