On Thu, 17 Jun 2010 13:45:17 -0500 Dan McGee wrote:

Sounds like a blast from the past: http://wiki.archlinux.org/index.php/Security_Task_Force http://code.google.com/p/arch-sheriff/

Best of luck this time around.

-Dan

As I've mentioned before, I don't think getting the processes in place will be that hard if we modify Gentoo's way of doing things to suit Arch. Gentoo's docs are all cc-by-sa licensed so it shouldn't be an issue. The mailing lists for vulnerabilities exist that can be used to check against the packages in Arch. What is needed are volunteers who: 1. Check for vulnerabilities 2. Know how to use PKGBUILDS and abs 3. Can spare some time to send announcements, create interim PKGBUILDs and file security issues on the bug tracker. It may well turn out to be a one man show for the immediate future, but I'm prepared for that. Ananda

I think there is much more that can be done besides the short list from Ananda. The thing you have to remember is that "security" does not mean "I'm running the newest code.". Things to remember: 1. There is no such thing as "secure". 2. Proper security consists of multiple layers of defense. Additional examples of things the AST could do: 1. Propose changes to default configuration files to be "more secure", and have more documentation around setting up services in a more secure fashion. 2. Assist with SELinux & GRsecurity projects. 3. Propose changes to initscripts to make sure software drops privileges and chroots where possible, or at least make it easier to enable such features. 4. pie / ssp 5. PaX 6. Audits This list is by no means complete, but the end goal should be to make things more secure. The other thing to remember is that just because you are running the latest rev of code, it doesn't mean there aren't vulnerabilities, or unpatched issues. Developers don't always consider issues that could be security issues to be security issues, or don't they understand the security implications of certain issues. Lastly, just because Arch is a rolling release it doesn't mean that everybody that uses it just updates everything at a whim. Some people do believe in change control and it may be useful for those people to be aware of security issues in certain packages that need to be updated. Not everybody does a daily/weekly/monthly system update. For some people "stability" is a feature. Some people might choose to upgrade packages which are security conscious while taking caution to upgrade a package they are dependent on. TOFU. -Miah On Thu, Jun 17, 2010 at 3:06 PM, Jeroen Op 't Eynde wrote:

On Thu, 17 Jun 2010 20:57:56 +0200, Ananda Samaddar wrote:

1. Check for vulnerabilities

...

2. Know how to use PKGBUILDS and abs 3. Can spare some time to send announcements, create interim PKGBUILDs and file security issues on the bug tracker.

1. [testing] users do that 2. [testing] users, Devs and TUs (should) know this 3. see 1 and 2

IMHO, Arch's rolling release and cutting/bleeding edge kicks the need for a security team. Just do your one man thing like any testing user. The only thing I can think of in ways of security is signed packages, so write some code if you are a coder or put some time in a plan on how to achieve this instead of starting a strange vague unofficial security mailing list. If you do have a lot of security issues about arch, just flood the arch-general mailing list. If the devs see 'a lot' of messages concerning security, they might come back on the arch-security mailing list. Just be patient.

-- To read: http://en.wikipedia.org/wiki/Posting_style#Bottom-posting

Comments interspersed on a few points. On Thu, 2010-06-17 at 15:35 -0700, Miah Johnson wrote:

I think there is much more that can be done besides the short list from Ananda. The thing you have to remember is that "security" does not mean "I'm running the newest code.".

Things to remember: 1. There is no such thing as "secure". 2. Proper security consists of multiple layers of defense.

Additional examples of things the AST could do: 1. Propose changes to default configuration files to be "more secure", and have more documentation around setting up services in a more secure fashion.

Except with very good reasons, I doubt its a good idea to make more changes to default configuration files than necessary, its against the 'upstream as much as possible' policy. The rest sounds fine, though I'm not sure about point 3 since I'm not familiar with what sort of control the initscript has at the moment.

2. Assist with SELinux & GRsecurity projects. 3. Propose changes to initscripts to make sure software drops privileges and chroots where possible, or at least make it easier to enable such features. 4. pie / ssp 5. PaX 6. Audits

This list is by no means complete, but the end goal should be to make things more secure. The other thing to remember is that just because you are running the latest rev of code, it doesn't mean there aren't vulnerabilities, or unpatched issues. Developers don't always consider issues that could be security issues to be security issues, or don't they understand the security implications of certain issues.

Lastly, just because Arch is a rolling release it doesn't mean that everybody that uses it just updates everything at a whim. Some people do believe in change control and it may be useful for those people to be aware of security issues in certain packages that need to be updated. Not everybody does a daily/weekly/monthly system update. For some people "stability" is a feature. Some people might choose to upgrade packages which are security conscious while taking caution to upgrade a package they are dependent on.

My OPINION is that Arch is not a distro for those who do not want to do regular total updates. Of course, some have individual packages in NoUpgrade, but the number of problems which crop up which come down to "you didn't run pacman -Syu!" is an indicator of why its a bad idea.

On Friday 18 of June 2010 00:35:19 Miah Johnson wrote:

I think there is much more that can be done besides the short list from Ananda. The thing you have to remember is that "security" does not mean "I'm running the newest code.".

Things to remember: 1. There is no such thing as "secure". 2. Proper security consists of multiple layers of defense.

Additional examples of things the AST could do: 1. Propose changes to default configuration files to be "more secure", and have more documentation around setting up services in a more secure fashion. 2. Assist with SELinux & GRsecurity projects. 3. Propose changes to initscripts to make sure software drops privileges and chroots where possible, or at least make it easier to enable such features. 4. pie / ssp I like this! btw, anyone tried/knows about rootless(without root privileges) X? There was a hype about his with KMS, I've heard MeeGo uses this. I've read some articles at phoronix,ubuntu has a blueprint plan for it,.. once I have time, i'll write more on the topic.

5. PaX 6. Audits

This list is by no means complete, but the end goal should be to make things more secure. The other thing to remember is that just because you are running the latest rev of code, it doesn't mean there aren't vulnerabilities, or unpatched issues. Developers don't always consider issues that could be security issues to be security issues, or don't they understand the security implications of certain issues.

Lastly, just because Arch is a rolling release it doesn't mean that everybody that uses it just updates everything at a whim. Some people do believe in change control and it may be useful for those people to be aware of security issues in certain packages that need to be updated. Not everybody does a daily/weekly/monthly system update. For some people "stability" is a feature. Some people might choose to upgrade packages which are security conscious while taking caution to upgrade a package they are dependent on.

TOFU. -Miah

On Thu, Jun 17, 2010 at 3:06 PM, Jeroen Op 't Eynde wrote:

...

On Thu, 17 Jun 2010 20:57:56 +0200, Ananda Samaddar

wrote: 1. Check for vulnerabilities

...

2. Know how to use PKGBUILDS and abs 3. Can spare some time to send announcements, create interim PKGBUILDs and file security issues on the bug tracker.

1. [testing] users do that 2. [testing] users, Devs and TUs (should) know this 3. see 1 and 2

IMHO, Arch's rolling release and cutting/bleeding edge kicks the need for a security team. Just do your one man thing like any testing user. The only thing I can think of in ways of security is signed packages, so write some code if you are a coder or put some time in a plan on how to achieve this instead of starting a strange vague unofficial security mailing list. If you do have a lot of security issues about arch, just flood the arch-general mailing list. If the devs see 'a lot' of messages concerning security, they might come back on the arch-security mailing list. Just be patient.

-- To read: http://en.wikipedia.org/wiki/Posting_style#Bottom-posting

-- Marek Otahal :o)

On Thu, Jun 17, 2010 at 6:12 PM, Burlynn Corlew Jr wrote:

I am going to vote that you please do not CC all of this to arch-general. Many of us are not concerned with this, and already this afternoon I've seen enough mail regarding it that I can see it as a problem. The arch-security list has been denied, and it seems to me all this is doing is trying to circumvent the denial. Your google group is your business, but I feel that forwarding to arch-general, the most popular list we have, is unfair to those who do not wish to be involved.

beh, finally :-D and i agree with others that if you're not interested in following the rolling release for 'security reasons' then you're probably headed for more complications than it's worth. security is a vast a wide concept, full of crevasses and bear traps. 'securing' and auditing an entire distribution full of a heterogeneous software is the job of a full-time paid staff of security experts, engineers, and upstream developers. even that may not produce much. anything less will add complexity due to naive diagnosis, and will not be worth the massive amount of time expended in the process. however, you can be a security conscious administrator. learn in depth the specific systems/daemons/applications that you depend on. learn them, and really understand their roles, relationships, and I/O points in relation to the other software on the system. monitor your systems and look for that which does not fit. security is the responsibility of those deploying, not those packaging. it requires end-to-end oversight and complete configuration toward a specific and particular purpose; something that is not possible for those creating a distribution for a generic, multi-purpose user base.

On Thu, Jun 17, 2010 at 10:18 PM, Jeffrey 'jf' Lim wrote:

On Fri, Jun 18, 2010 at 8:33 AM, C Anthony Risinger wrote:

...

security is the responsibility of those deploying, not those packaging.  it requires end-to-end oversight and complete configuration toward a specific and particular purpose; something that is not possible for those creating a distribution for a generic, multi-purpose user base.

2 words. Debian, and SSH.

Did you mean ssl? Andres P

On Fri, Jun 18, 2010 at 1:18 AM, Jeffrey 'jf' Lim wrote:

ah yes, SSL! sorry :)

On 2006-05-01 22:34:12, Ulf Möller, openssl developer [1], responded [2] to openssl packager Kurt Roeckx [3] saying that he was for applying the patch just to keep valgrind quiet. But openssl doesn't like to talk about that, and neither does slashdot for that matter. For a distro packager, the maximum authority regarding what to do with a given piece of software is upstream and common sense. If upstream says it's a ok, then common sense takes a backseat during technical discussions. Not to mention that initializing variables like that is undefined and bound to *always* cause confusion. Andres P [1] http://openssl.org/about [2] http://marc.info/?l=openssl-dev&m=114652287210110&w=2 [3] http://qa.debian.org/developer.php?login=kurt@roeckx.be