[arch-general] New Google Group for discussion and notices on Arch security.
I've created a Google Group here for discussion around creating an Arch Security Team: http://groups.google.com/group/arch-security Please join it if you're interested. The reason for this group is in response to my rejected suggestion for an arch-security mailing list. I'll CC any policy or process suggestions to arch-general, but when announcements happen and also discussion regarding specific vulnerabilities and mitigation they won't be CCed. If an Arch Security Team comes coalesces and the Devs are happy to integrate us officially then we can consider deleting the group and if possible transferring the archives to archlinux.org. Ananda
On Thu, Jun 17, 2010 at 1:32 PM, Ananda Samaddar <ananda@samaddar.co.uk> wrote:
I've created a Google Group here for discussion around creating an Arch Security Team:
http://groups.google.com/group/arch-security
Please join it if you're interested. The reason for this group is in response to my rejected suggestion for an arch-security mailing list. I'll CC any policy or process suggestions to arch-general, but when announcements happen and also discussion regarding specific vulnerabilities and mitigation they won't be CCed.
If an Arch Security Team comes coalesces and the Devs are happy to integrate us officially then we can consider deleting the group and if possible transferring the archives to archlinux.org.
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
Cool. I just joined. -Miah On Thu, Jun 17, 2010 at 11:45 AM, Dan McGee <dpmcgee@gmail.com> wrote:
On Thu, Jun 17, 2010 at 1:32 PM, Ananda Samaddar <ananda@samaddar.co.uk> wrote:
I've created a Google Group here for discussion around creating an Arch Security Team:
http://groups.google.com/group/arch-security
Please join it if you're interested. The reason for this group is in response to my rejected suggestion for an arch-security mailing list. I'll CC any policy or process suggestions to arch-general, but when announcements happen and also discussion regarding specific vulnerabilities and mitigation they won't be CCed.
If an Arch Security Team comes coalesces and the Devs are happy to integrate us officially then we can consider deleting the group and if possible transferring the archives to archlinux.org.
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
On Thu, 17 Jun 2010 13:45:17 -0500 Dan McGee <dpmcgee@gmail.com> 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
On Thu, 17 Jun 2010 20:57:56 +0200, Ananda Samaddar <ananda@samaddar.co.uk> 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
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 <jeroen@xprsyrslf.be>wrote:
On Thu, 17 Jun 2010 20:57:56 +0200, Ananda Samaddar <ananda@samaddar.co.uk> 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
On Fri, 18 Jun 2010 00:35:19 +0200, Miah Johnson <miah@chia-pet.org> wrote:
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
First of all, please don't top post. It is really annoying. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? Back on topic: Start a security team while there isn't anything like secure? Alright I get the point, but I guess arch has the natural ability to become faster stable just because of the bleeding edge. Software bugs get tackled faster, patch are quickly spread, not waiting for months like many other distros. I know running the newest code doesn't mean secure, but that choice is up to the user (check the svn and use abs and so on). Other examples, hmm. You can still propose changes, you don't need a team to write a patch for a configuration file or the initscripts. SELinux is not even in community, maybe apply for becoming a TU for it? Or help out at Fedora or wherever it is developed? I don't know much about GRsecurity/PaX/SSP/Audits, but check the Wiki and try to help out there, discus it there. People who are interested should be following those pages and contribute, the same for SELinux. The Wikipages look really nice. I don't know pie, but that would probably have something to do with GRsecurity too. I guess most of the things are already there, some people want to give it a name. I'm not stopping you from a team, but I just don't believe in it after seeing so many fails. (I'm not a Dev nor a TU, just giving my opinion.) -- 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 Fri, 18 Jun 2010 01:00:57 +0200, Ng Oon-Ee <ngoonee@gmail.com> wrote:
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.
+1 Forgot to react on that part. -- To read: http://en.wikipedia.org/wiki/Posting_style#Bottom-posting
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 <jeroen@xprsyrslf.be>wrote:
On Thu, 17 Jun 2010 20:57:56 +0200, Ananda Samaddar <ananda@samaddar.co.uk>
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 1:32 PM, Ananda Samaddar <ananda@samaddar.co.uk>wrote:
I've created a Google Group here for discussion around creating an Arch Security Team:
http://groups.google.com/group/arch-security
Please join it if you're interested. The reason for this group is in response to my rejected suggestion for an arch-security mailing list. I'll CC any policy or process suggestions to arch-general, but when announcements happen and also discussion regarding specific vulnerabilities and mitigation they won't be CCed.
If an Arch Security Team comes coalesces and the Devs are happy to integrate us officially then we can consider deleting the group and if possible transferring the archives to archlinux.org.
Ananda
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.
On Thu, Jun 17, 2010 at 6:12 PM, Burlynn Corlew Jr <burlynn@gmail.com> 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 Fri, Jun 18, 2010 at 8:33 AM, C Anthony Risinger <anthony@extof.me> 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. -jf -- "Every nonfree program has a lord, a master -- and if you use the program, he is your master." --Richard Stallman "It's so hard to write a graphics driver that open-sourcing it would not help." -- Andrew Fear, Software Product Manager, NVIDIA Corporation http://kerneltrap.org/node/7228
On Thu, Jun 17, 2010 at 10:18 PM, Jeffrey 'jf' Lim <jfs.world@gmail.com> wrote:
On Fri, Jun 18, 2010 at 8:33 AM, C Anthony Risinger <anthony@extof.me> 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:25 PM, Andres P <aepd87@gmail.com> wrote:
On Thu, Jun 17, 2010 at 10:18 PM, Jeffrey 'jf' Lim <jfs.world@gmail.com> wrote:
On Fri, Jun 18, 2010 at 8:33 AM, C Anthony Risinger <anthony@extof.me> 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?
ah yes, SSL! sorry :) -jf -- "Every nonfree program has a lord, a master -- and if you use the program, he is your master." --Richard Stallman "It's so hard to write a graphics driver that open-sourcing it would not help." -- Andrew Fear, Software Product Manager, NVIDIA Corporation http://kerneltrap.org/node/7228
On Fri, Jun 18, 2010 at 1:18 AM, Jeffrey 'jf' Lim <jfs.world@gmail.com> 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
On Fri, Jun 18, 2010 at 2:33 PM, Andres P <aepd87@gmail.com> wrote:
On Fri, Jun 18, 2010 at 1:18 AM, Jeffrey 'jf' Lim <jfs.world@gmail.com> 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.
cool. I wasnt aware of that. I was aware that there was some form of silence regarding what to do. But as for actually saying ok... hm. Agree with the point about making sense to defer to upstream for the final word. -jf
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
participants (10)
-
Ananda Samaddar
-
Andres P
-
Burlynn Corlew Jr
-
C Anthony Risinger
-
Dan McGee
-
Jeffrey 'jf' Lim
-
Jeroen Op 't Eynde
-
Marek Otahal
-
Miah Johnson
-
Ng Oon-Ee