You are not logged in.

#1 2008-02-18 14:40:51

VikM
Member
Registered: 2007-11-10
Posts: 50

Arch approach to security

The recent kernel bug brought some forum posts because the distrowatch error about Arch. Distrowatch was wrong but there are some things that might keep security conscious people away from Arch:
- change logs. For example php 5.2.5-4 was released a few days ago. Why? Is there a critical bug-fix, so I should upgrade as soon as possible, or can I wait until my regular update schedule? (Otherwise php is a great package in arch, thanks Pierre)
- some packages are quickly updated, some not. See http://bugs.archlinux.org/task/8613 from 2007-11-20 to 2008-02-11 to apply some simple patches. Even 2007-11-20 was quite late. Is someone looking on others distros security changelogs or security sites to see what is happening around?
- the arch way, as vanilla as possible, config files as default as possible is not always the best approach. The denyhosts problem, the xorg default config listening on the net are two examples fixed as result of users requests, great, but they where obvious... One of the reasons php is great for me is because it is not quite the arch way, it is patched (Suhosin)
- since when is iptables 1.4.0 out? 2007-12-22. Not crucial, but again this raises the question "how much does Arch care about security?"
Not to mention Fedora/RedHat/Gentoo/OpenBSD (at least) usage of hardening gcc switches for theirs packages. These switches are in vanilla gcc since 2005. Fedora/RedHat also uses the vanilla kernel's selinux.

Last edited by VikM (2008-02-18 14:52:46)

Offline

#2 2008-02-18 14:49:14

anykey
Member
From: Trier, Germany
Registered: 2004-06-12
Posts: 79

Re: Arch approach to security

While I support this idea (this might put off some users from Arch), some questions would be where to place such logs, how long should they be archived, would all maintainers do it, and so on.
The thing I would love to see would be to incorporate such things on the shell, maybe manpage-style viewable, with (maybe) pacman warning me that this is in fact a security fix and what fix it is, in addition to online HTMLized archives; but others wouldn't prefer this I bet.

Just some thoughts -- and note I do not request such functionality because I would not be able to spare the time to help with development myself, unfortunately, so don't take my ramblings seriously.

Last edited by anykey (2008-02-18 14:50:16)

Offline

#3 2008-02-18 14:49:43

bangkok_manouel
Member
From: indicates a starting point
Registered: 2005-02-07
Posts: 1,554

Re: Arch approach to security

[OT] got a 404 with the link [/OT]


All design goals must be phrased in such a way that it is hard to use them as slogans to justify stupidity.

Offline

#4 2008-02-18 14:51:28

dolby
Member
From: 1992
Registered: 2006-08-08
Posts: 1,581

Re: Arch approach to security

i guess it depends on the developer a lot too on when a package will be updated , but users who feel a security or package update is urgent for a relatively important package they should not hesitate to post on the arch-general mailing list


There shouldn't be any reason to learn more editor types than emacs or vi -- mg (1)
[You learn that sarcasm does not often work well in international forums.  That is why we avoid it. -- ewaller (arch linux forum moderator)

Offline

#5 2008-02-18 14:57:24

VikM
Member
Registered: 2007-11-10
Posts: 50

Re: Arch approach to security

to bangkok_manouel: I corrected the link
to dolby: Arch is community oriented, I agree. the Arch developers are friendly and receptive, agree too, but they should not rely on users to show them links about security issues.

Offline

#6 2008-02-18 14:59:56

FeatherMonkey
Member
Registered: 2007-02-26
Posts: 313

Re: Arch approach to security

Of course they should we don't pay them lets not put more work load on them, I'm sure they have enough volunteer work already.

As you said its a community distro which means the community needs to get involved, not to say some bits you highlighted aren't worthy of mentioning.

But the solution needs to come from the community.

Edit
@ the mo it sounds like thanks for the free work but its not good enough, not very nice to the Devs who are volunteering there time.

Last edited by FeatherMonkey (2008-02-18 15:04:16)

Offline

#7 2008-02-18 15:13:19

bangkok_manouel
Member
From: indicates a starting point
Registered: 2005-02-07
Posts: 1,554

Re: Arch approach to security

FeatherMonkey wrote:

@ the mo it sounds like thanks for the free work but its not good enough, not very nice to the Devs who are volunteering there time.

That's also how it works with community distros. With this kind of discussions, I bet we'll see people willing to get involved in a security team... FWIW, mini-logs from CVS are enough for me and should I want to update, I'll just makepkg...


All design goals must be phrased in such a way that it is hard to use them as slogans to justify stupidity.

Offline

#8 2008-02-18 15:36:17

FeatherMonkey
Member
Registered: 2007-02-26
Posts: 313

Re: Arch approach to security

Though here I think I begin to talk myself in circles.

I do think some points that have been highlighted perhaps may need looking at, I for one don't know not to much about security. But isn't that the beauty of the Arch I mean with the exception of the bug report.(These types, remembering I understand little about the fix, seem oversight to me it will happen, we're all human, what would be a solution?)

Taking the other 2 examples ABS gives us this option, and still fits into KISS. Surely our PC's security to a certain extent should be down to us, are you saying no? I mean isn't there a thread around in regards to GPG signing. Theres for and against to this too, if its a concern its highly unlikely you would look at Arch, not sure gpg signing makes it any more or less secure myself. To me it seems more a placebo without a physical web of trust.

I have to say I found the kernel update quicker than Suse says plenty to me. I mean we quiz what about xxx version well what about other distro's I suspect its highly unlikely that they will be running as new packages as Arch users generally do. We don't have to wait for back port security fixes its likely we just end up with a newer version that's fixed and perhaps some time before the fix is backported.

Edit
Looking at distrowatch it seems none are running iptables 1.4.0 not the best perhaps and perhaps I may end up corrected. It also seems Arch is the only one with php 5.2.5 to which distrowatch doesn't find either.

Last edited by FeatherMonkey (2008-02-18 16:11:13)

Offline

#9 2008-02-18 15:48:45

rson451
Member
From: Annapolis, MD USA
Registered: 2007-04-15
Posts: 1,233
Website

Re: Arch approach to security

VikM wrote:

The recent kernel bug brou...

i admit i haven't read the rest of the posts in this thread, but my thoughts on this are arch feels the same way about security as it does about everything else. if you want it, get it.  abs is there to allow you to update whatever you want whenever you want.  if you think a package is out of date, you can update it.  that's how i understand it anyway.


archlinux - please read this and this — twice — then ask questions.
--
http://rsontech.net | http://github.com/rson

Offline

#10 2008-02-18 16:10:49

dyscoria
Member
Registered: 2008-01-10
Posts: 1,007

Re: Arch approach to security

FeatherMonkey wrote:

Taking the other 2 examples ABS gives us this option, and still fits into KISS. Surely our PC's security to a certain extent should be down to us

That is true, that with arch the user has the choice. Arch "allows an individual user to shape the system according to their own needs." However, who would want to shape an insecure system with exploits in the kernel? Unless you're using a 'testing' or 'unstable' branch of any particular distribution, security should be a foremost concern and it would seem appropriate to provide security to the user with little effort from the user side. If exploits are popping up, sure a user could use ABS to patch up their kernel or whatever other package, but not everyone can or should be expected to do so.

Perhaps security is more important in a server oriented distro like Debian, but even for the average desktop user security is still vital and the user shouldn't necessarily be made to work to get security.


flack 2.0.6: menu-driven BASH script to easily tag FLAC files (AUR)
knock-once 1.2: BASH script to easily create/send one-time sequences for knockd (forum/AUR)

Offline

#11 2008-02-18 16:13:39

FeatherMonkey
Member
Registered: 2007-02-26
Posts: 313

Re: Arch approach to security

I can't but it got fixed quicker than Suse(Perhaps a distro, where its even less likely a user can patch a kernel) so what is the complaint because I didn't get told it was fixed?

And you won't find php 5.2.5 on Suse iirc Arch's php was hardened for a little longer than Suse too.

Last edited by FeatherMonkey (2008-02-18 16:19:06)

Offline

#12 2008-02-18 16:22:00

VikM
Member
Registered: 2007-11-10
Posts: 50

Re: Arch approach to security

FeatherMonkey if you run linux only on your desktop and another 2-3 toy servers, Arch it's great and fun. I experienced some kde, flash, and all kind of desktop problems along the years, I don't complain about this. I know I can recompile packages, I can surf the web for advisories, an so on. I'm doing this since RedHat 6.X.

The point is that if you run it on 25, 50 or 250 servers, some of them quite busy, some of them having some people behind expecting them to work, you may see the value of a distribution like CentOS. On production servers you can't upgrade every day. Upgrading weekly or monthly with Arch is doable without problem, but if there is a security upgrade you might want to upgrade the package as soon as possible. For this some visible, explicit changelogs are more than welcome. Even more, the user of a distro can't search the web for security related info about all packages (s)he uses. It's the distro job.

The KISS Arch way is great, but this is not an excuse for not patching even if the upstream does not, or for releasing packages with unsafe defaults. Maybe the examples from my fisrt post are no relevant for you, but they rise that question in my mind: what is Arch approach to security? Just keeping packages up to date is not enough. Patching is sometimes required, safer than vanilla defaults configs should be imposed on some packages, safer compile-time options don't hurt, and, again, changelogs.

I'm not telling what a bad distro Arch is, I use it and I like it. I'm just asking some legitimate questions. I think there is place for improvement in this direction.

So, I'm very curious what other people think about security in Arch.

Last edited by VikM (2008-02-18 16:23:55)

Offline

#13 2008-02-18 16:25:16

dyscoria
Member
Registered: 2008-01-10
Posts: 1,007

Re: Arch approach to security

VikM wrote:

what is Arch approach to security?

+1


flack 2.0.6: menu-driven BASH script to easily tag FLAC files (AUR)
knock-once 1.2: BASH script to easily create/send one-time sequences for knockd (forum/AUR)

Offline

#14 2008-02-18 16:27:11

FeatherMonkey
Member
Registered: 2007-02-26
Posts: 313

Re: Arch approach to security

But I keep pointing to bits which actually beat these other ones. Suse 2 days after Arch if I remember rightly. to me there approach seems better than Suse.

Mileage varies I guess, but I suspect that's the same for and against so when did centos update when did rhel update
rhel 2008-02-12 16:54
cento 2008-02-13 03:27
Suse 2008-02-12 12:43

Lets not con ourselves that the security notifications don't come at the same time as fix, I certainly know that is correct for Suse.

As for defaults we all know that but its KISS. Price of the game Arch will be pretty vanilla.

Better than Suse, for 2 days I may of been open to an exploit for Arch, 4 days for Suse since the upstream fix.

What I would be interested in is when did the Various distro's start hardening PHP because I'm sure that Arch was before Suse, but wouldn't really know how to find out.

Last edited by FeatherMonkey (2008-02-18 16:42:57)

Offline

#15 2008-02-18 16:58:47

Pudge
Arch Linux f@h Team Member
Registered: 2006-01-23
Posts: 298

Re: Arch approach to security

VikM wrote:

The recent kernel bug brought some forum posts because the distrowatch error about Arch. Distrowatch was wrong but there are some things that might keep security conscious people away from Arch:

As I stated in This thread, post #25, if you go to the ftp://locke.suu.edu/linux/dist/archlinu … /os/x86_64
mirror, you will see that this mirror is out of date and still has kernel  2.6.23.14-1 in the core repo.  How can you say Distrowatch was wrong about the date the kernel fix was available when we have mirrors that STILL don't have it available.  In all fairness, how do we know what mirror Distrowatch was checking?  Was it fair to assume they should have checked the Archlinux site as a reference?

If you want to discuss how fast important security fixes are made available, then you must take into account the reliability of our mirror sites.  Especially when Arch Linux scolds you for using the Arch Linux mirror.  At this point, Arch cannot afford the bandwidth for everyone to get their updates from the Arch server.  Arch depends on the mirrors to continue to operate.  If you want to question the Arch approach to security, then you need to back it up with donations that will allow Arch to afford the bandwidth necessary for the only mirror they have control over.

Pudge

Last edited by Pudge (2008-02-18 17:02:39)

Offline

#16 2008-02-18 17:06:32

z0phi3l
Member
From: Waterbury CT
Registered: 2007-11-26
Posts: 278

Re: Arch approach to security

VikM wrote:

FeatherMonkey if you run linux only on your desktop and another 2-3 toy servers, Arch it's great and fun. I experienced some kde, flash, and all kind of desktop problems along the years, I don't complain about this. I know I can recompile packages, I can surf the web for advisories, an so on. I'm doing this since RedHat 6.X.

The point is that if you run it on 25, 50 or 250 servers, some of them quite busy, some of them having some people behind expecting them to work, you may see the value of a distribution like CentOS. On production servers you can't upgrade every day. Upgrading weekly or monthly with Arch is doable without problem, but if there is a security upgrade you might want to upgrade the package as soon as possible. For this some visible, explicit changelogs are more than welcome. Even more, the user of a distro can't search the web for security related info about all packages (s)he uses. It's the distro job.

The KISS Arch way is great, but this is not an excuse for not patching even if the upstream does not, or for releasing packages with unsafe defaults. Maybe the examples from my fisrt post are no relevant for you, but they rise that question in my mind: what is Arch approach to security? Just keeping packages up to date is not enough. Patching is sometimes required, safer than vanilla defaults configs should be imposed on some packages, safer compile-time options don't hurt, and, again, changelogs.

I'm not telling what a bad distro Arch is, I use it and I like it. I'm just asking some legitimate questions. I think there is place for improvement in this direction.

So, I'm very curious what other people think about security in Arch.

Isn't that the reason you runt a Test server? To see what updates are available and test them out before bringing the production machines down for updates? I mean it would be nice to have another way of being notified, but in your example you would still run it on your test server first, so doing a pacman -Syu on it daily should be enough, or did I miss your point completely?

Offline

#17 2008-02-18 17:11:08

fwojciec
Member
Registered: 2007-05-20
Posts: 1,411

Re: Arch approach to security

Pudge wrote:

In all fairness, how do we know what mirror Distrowatch was checking?  Was it fair to assume they should have checked the Archlinux site as a reference?

It seems Ladislav simply checked the kernel version on the Arch main page (which was still 2.6.24.1) without noticing that it was a second revision of the package (2.6.24.1-2) which already included the fix.  It seems he hasn't inquired further about it, he hasn't even read the "Latest News" post from the main page which included information about the fix.  Oh well...

Offline

#18 2008-02-18 18:06:58

VikM
Member
Registered: 2007-11-10
Posts: 50

Re: Arch approach to security

z0phi3l, you did missed my point a little, it's not about testing the upgrades. It's about making the decision to upgrade a certain package now or later. Even if the upgrade is ok, I might want to delay it, if it is not a security fix.

Offline

#19 2008-02-20 17:07:24

KimTjik
Member
From: Sweden
Registered: 2007-08-22
Posts: 715

Re: Arch approach to security

Pudge wrote:

If you want to discuss how fast important security fixes are made available, then you must take into account the reliability of our mirror sites.  Especially when Arch Linux scolds you for using the Arch Linux mirror.  At this point, Arch cannot afford the bandwidth for everyone to get their updates from the Arch server.  Arch depends on the mirrors to continue to operate.  If you want to question the Arch approach to security, then you need to back it up with donations that will allow Arch to afford the bandwidth necessary for the only mirror they have control over.

As guilty of writing some comments at DW you're free to through stones at me! big_smile Why do I do it? I don't know. Maybe too many tea time breaks. DW's comment section is a mine field so I probably do best in ignoring it.

Anyway, the synchronisation of mirrors can be an issue with many other distributions as well, even though their budget is bigger and maybe have corporation support. So would more money necessarily make all mirrors working faster?

The mirrors I use for Arch here in Sweden tend to be some few hours behind, but not more. I have no insight in how this is working, hence I'm asking since some mirrors obviously are quickly updated and as you say Pudge some are slower.

Another thought: even though wasting my time writing those comments at DW's, I at least think it contributed to that Ladislav explained his view on the topic. For him the main question is obviously not about whether updates are done or not in due time, but more about, as he says, whether a distribution conforms to the "real UNIX security infrastructure", and his understanding of this term is rigid. On the other hand I don't see any signs of Arch folks being overly interested in getting DW to advertise Arch, and why be? I'm confident that Arch will continue to develop positively, not that I can boost about being a long time Arch user, and details like this might eventually change or fall into its places as time goes by, thanks to its active developers and community.

Last edited by KimTjik (2008-02-20 17:08:35)

Offline

#20 2008-02-20 17:53:37

fwojciec
Member
Registered: 2007-05-20
Posts: 1,411

Re: Arch approach to security

KimTjik: You comments there were respectful and I agree with you...  Nobody is going to throw be throwing stones at you because of them, I think...  I would be a better target in either case tongue

But after commenting earlier I will not write comments there anymore -- there is no point.  I'm convinced that Ladislav is not interested in having a genuine debate about the issue he had raised with his article or in making amends for his mistakes; his way is, after all, "the correct Unix way".  His recent comments are  disappointingly arrogant and condescending -- I expect that neither his credibility nor his "security announcements" agenda will benefit from this attitude.  What amused me the most is that it turns out that it is Arch that's responsible for the mistakes in his story (comment #85).  Oh well, I think that pretty much sums it up for me.

Offline

#21 2008-02-21 09:36:33

adlucem
Member
Registered: 2007-07-19
Posts: 28

Re: Arch approach to security

I won't talk about fixes, only about security warnings. Ladislav has a "one solution for all" in mind, and it's a mailing list. (That's what he looked for on Arch, he didn't find it, and thus he got his facts wrong). Of course, Arch doesn't have to agree with his view.

The Latest News RSS feed is low volume, and someone said that the dev mailing list is low volume too. Regarding the Latest News, the mention of the security risk (not a warning mind you, the annoucememt of a fix) was at the end of the message. The fact is, the majority of Arch users doesn't subscribe to the dev ML, so the security risk had very little visibility.

So, wouldn't it be an improvment to have a channel dedicated to security warnings only ? I don't know how much manpower setting up a Security RSS feed would take, but if Arch can manage it, my opinion is that it would be an improvment.


PS: I'm a linux -and security- noob - and I think Arch is great.


"The rules of Go are so elegant, organic and rigorously logical that if intelligent life forms exist elsewhere in the universe they almost certainly play Go." E. Lasker, International Chess Master.

Offline

#22 2008-02-21 11:17:58

neotuli
Lazy Developer
From: San Francisco, CA
Registered: 2004-07-06
Posts: 1,201
Website

Re: Arch approach to security

There was a very good community-run effort for some security advisories at some point [1] [2]. I thought it was pretty cool, but I'm not so sure what happened to it. If anyone wants to pick it up again, I think it'd be pretty nifty.

[1]http://wiki.archlinux.org/index.php/Security_Task_Force
[2]http://jjdanimoth.netsons.org/alsw.html


The suggestion box only accepts patches.

Offline

#23 2008-02-22 05:18:49

McQueen
Member
From: Arizona
Registered: 2006-03-20
Posts: 382

Re: Arch approach to security

adlucem wrote:

So, wouldn't it be an improvment to have a channel dedicated to security warnings only ? I don't know how much manpower setting up a Security RSS feed would take, but if Arch can manage it, my opinion is that it would be an improvment.

Security updates and concerns are an important subject and should have a high degree of visibility. A security RSS feed would go a long way toward providing this. It would definitely not be a glamorous position, but considering the necessity of the topic, opening up a dedicated developer position to coordinate the security alerts, issues, and responses would be a prudent move on the part of those who have the authority to recruit such a person.


/path/to/Truth

Offline

#24 2008-02-23 02:30:16

B-Con
Member
From: USA
Registered: 2007-12-17
Posts: 553
Website

Re: Arch approach to security

The biggest security issue I have right now is the lack of signed packages. SSL would be too server-straining to use, but signing all the packages wouldn't be as strenuous. Generate a hash, encrypt it with Arch's private key, send this signature out with each package.

This is the list of problems to be solved, that I see, to achieve package signing:

- Arch's public key(s) must be distributed. Obviously they would be included in the distro by default, and should also be provided for download on the website in case the local copies gets corrupted, the user doesn't trust the download source (aka: bittorrent), of (forbid) the keys get compromised and a new public key needs to be redistributed. There exist cheap/free CA's that could sign a certificate with the public key so the certificate could be put on the website and trivially (resource wise) distributed.

- makepkg must be configured to auto-generate a signature. Because Arch's personal private key cannot be distributed to all users, makepkg.conf would need an option to specify the source of the users private key. This key would then be used to sign the package. (Obviously, makepkg would need a flag to allow the user to not use a key, as not all users need to sign their own packages before installing them. In fact, this behavior could be default.)

- pacman needs the feature to automatically validate the signature, if one is provided. (Default behaviors and over-rides for packages without signatures, with bad signatures, etc, would need to be decided on.)

- A signature format needs to be established. This is the obnoxious part, as the other issues don't seem harder than any other features already implemented in pacman/makepkg. (Not that I'm trivializing the devs' time. ;-) ) Designing this correctly would be key. [edit]I went a-Googlin', found this interesting link, it describes RPM, DBC, FreeBSD, slackware, and emerge's way of doing package signing: http://www.edos-project.org/xwiki/bin/v … urityTopic . [/edit]

Last edited by B-Con (2008-02-23 02:53:45)

Offline

#25 2008-02-23 12:25:02

neotuli
Lazy Developer
From: San Francisco, CA
Registered: 2004-07-06
Posts: 1,201
Website

Re: Arch approach to security

Sounds good, now get on pacman-dev and get codin' wink


The suggestion box only accepts patches.

Offline

Board footer

Powered by FluxBB