Securing Arch...on the dev side

beniro · 2005-03-21 21:07:22

Hello...perusing the ocean of bull5*|+ today in response to the OSNews article, I saw one post that caught my eye, and so I'm posting it here:

Let's see, does Arch Linux have proper package QA, does it ship a firewall by default, does it use exec-shield, does it fortify binaries, does it use adresse space randomization, does it deploy SELinux?

Please don't get defensive, becuase I'm bringing this here to spark a conversation. I am not a true developer, so I'm just inquiring.

1. QA - This is much improved and getting better. I don't find this too intriguing. Skip it.

2. Firewall not included - Of course not...KISS. Skip it.

3. Exec-shield - This is a RedHat piece of code to add additional protection s against "stack, buffer or function pointer overflows": http://lwn.net/Articles/31032/

Would it be feasible/worth it to implement this in Arch?

4. Fortified binaries - I don't know what this is. What is it? Would it be good for Arch?

5. Address-space randomization - I read a bit on this...and immediately found this: http://www.stanford.edu/~blp/papers/asrandom.pdf

Would it be feasible/worth it to implement this in Arch?

6. SELinux - I know there was some talk here previously about setting up SELinux for Arch...but it takes some amount of work...

Would it be feasible/worth it to implement this in Arch?

The truth is that this conversation is just a bit out of my league, but I'm bringing this up in the hope that it sparks some conversation.

Or at least that I get informed some...

phrakture · 2005-03-21 21:13:04

that's all crap that business people will convince you they need on their servers....

it's a crock of crap...
these so called "business minded" people want to convince you that all this extra crap is needed, so they can then hire mediocre, lazy empolyees...

solution: hire one good admin. done.

anyway, all this crap has to do with server-grade stuff... arch linux is not made for the server - now I'm not saying it can't run a server... just don't expect it to jump through flaming hoops and bring you your newspaper....

god I hate OS news...

cactus · 2005-03-21 21:16:31

beniro wrote:

4. Fortified binaries - I don't know what this is. What is it? Would it be good for Arch?

Could be in regards to canary stack support. I think gcc has some support for this.
I believe OpenBSD uses canary support in their stack for everything, if I am not mistaken..

6. SELinux - I know there was some talk here previously about setting up SELinux for Arch...but it takes some amount of work...
Would it be feasible/worth it to implement this in Arch?

That would be an understatement. Look at how long it has taken redhat to get something even remotely workable. And they have tons of people.. The problem isn't installing it, per se, it is coming up with a decent set of rules. For a growing distro, this would be highly problematic. Every new daemon would need a new set of TE (type enforcement) rules, and these rules would have to be distributed and reloaded. It would either be impossible for someone to include custom compiled packages, or the default permission set would be so lax it would be pointless to use it..

I think it would be well worth it to have the infrastructure in place so that people can write their own rulesets, and implement selinux on their own...but rolling it into the distribution at this point does not make sense to me.

Same thing goes for any of the security implementations on top of the LSM, in my opinion (like lids).

darkcoder · 2005-04-28 23:28:11

phrakture wrote:

that's all crap that business people will convince you they need on their servers....

It's not crap. When dealing with servers, the best defense is to to be as secure as possible.

But, since Arch is more a desktop oriented distribution, none of these are really needed anyway by most users, and bringing them may cause incompatibilities and a little slower binaries.

darkcoder · 2005-04-29 04:08:46

Well, already has been established that Arch is not build for server use, but as any Linux distribution, it can be molded to work that way. I will try to provide as much info and be as neutral as possible. BTW, I haven't read the article you said.

Let's see, does Arch Linux have proper package QA

Every distro has its QA, even Arch. But, if they refer to Security Advisories, companies like RedHat, SuSE, Mandrake, Debian, Gentoo and any other server oriented distribution provide security advisories, which alert people where a program needs to be updated. Arch do not have that system, but since it allways has the latest program versions is not a big issue anyway.

I will use KDE as an example: a security issue is found, first fixed in HEAD branch, backported to the previous and still supported branches. They release and updated revision (example 3.3.2), and patches for downstream versions (for RH, MDK, Debian, and all the others). They got only the security patches, we got the new revision will all the security and non security fixes. Who got the best deal at the end?

does it ship a firewall by default

No, and easily resolved. While it would be in part nice to have a default one, the flexibility of Linux itself, and the simplicity that comes with Arch, having a default firewall rules will bring problems to many.

does it use exec-shield

No, this one is subjective. It brings a layer of security, but there are samples on the Net to bypass it. Also slows a bit the OS. The plus side, is very easy to implement, just one patch. Currently I have one under test on my PC, and have no problems at all.

does it fortify binaries

No, this one is also subjective. Enhance security, I think it also has been bypassed (not sure about this one). Slows even further the system, since applications must be specially compiled. And it is even more difficult to implement. First, gcc must be patched with a stack-smashing patch, and then the system packages must be recompiled with -fstack-protect or something like that.

adresse space randomization

No, but this one is provided by the exec-shield (or grsecurity) patch. If you patch the kernel, you get application and library space randomization as part of the security features.

does it deploy SELinux?

While provided by the base kernel sources, it is not installed by Arch. This one probably is the more difficult to implement. Adding the SELinux support on the kernel is a piece of cake, but you need to specify the rules that services will use. Neither RedHat and Gentoo which have been on this for a long time provide a problem-free ruleset. Also their rules cover only their packages, when you manually install sources like the qmailrocks package, you are on your own.

Arch Linux

#1 2005-03-21 21:07:22

Securing Arch...on the dev side

#2 2005-03-21 21:13:04

Re: Securing Arch...on the dev side

#3 2005-03-21 21:16:31

Re: Securing Arch...on the dev side

#4 2005-04-28 23:28:11

Re: Securing Arch...on the dev side

#5 2005-04-29 04:08:46

Re: Securing Arch...on the dev side

Board footer