FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux General Discussion

 
 
LinkBack Thread Tools
 
Old 06-17-2010, 10:35 PM
Miah Johnson
 
Default New Google Group for discussion and notices on Arch security.

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
>

Fri Jun 18 01:30:01 2010
Return-path: <gentoo-dev+bounces-41361-tom=linux-archive.org@lists.gentoo.org>
Envelope-to: tom@linux-archive.org
Delivery-date: Fri, 18 Jun 2010 00:59:16 +0300
Received: from pigeon.gentoo.org ([208.92.234.80]:55582 helo=lists.gentoo.org)
by s2.java-tips.org with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.69)
(envelope-from <gentoo-dev+bounces-41361-tom=linux-archive.org@lists.gentoo.org>)
id 1OPN7E-0005kb-I0
for tom@linux-archive.org; Fri, 18 Jun 2010 00:59:16 +0300
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 7CEEBE0D40;
Thu, 17 Jun 2010 22:38:24 +0000 (UTC)
X-Original-To: gentoo-dev@lists.gentoo.org
Delivered-To: gentoo-dev@lists.gentoo.org
Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183])
by pigeon.gentoo.org (Postfix) with ESMTP id 98CF8E0C9A
for <gentoo-dev@lists.gentoo.org>; Thu, 17 Jun 2010 22:37:52 +0000 (UTC)
Received: from [192.168.178.58] (e178091181.adsl.alicedsl.de [85.178.91.181])
(using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits))
(No client certificate requested)
by smtp.gentoo.org (Postfix) with ESMTP id CA3D21B4020
for <gentoo-dev@lists.gentoo.org>; Thu, 17 Jun 2010 22:37:51 +0000 (UTC)
Message-ID: <4C1AA3A9.2040204@gentoo.org>
Date: Fri, 18 Jun 2010 00:37:29 +0200
From: =?UTF-8?B?Q2jDrS1UaGFuaCBDaHJpc3RvcGhlciBOZ3V54buFbg==?=
<chithanh@gentoo.org>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100409 Gentoo/2.0.4-r1 SeaMonkey/2.0.4
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
MIME-Version: 1.0
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Adding AdobeFlash-10{,.1} licenses to EULA group
References: <4C169D32.5080706@gentoo.org> <20100616084022.2f3c84fe@vrm378-02.vrm378.am.mot.com> <4C18C761.5080909@gentoo.org> <201006180006.53669.polynomial-c@gentoo.org> <4C1A9E38.8050206@gmail.com>
In-Reply-To: <4C1A9E38.8050206@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Dale schrieb:
>>>>> One notable section is 7.6 in which Adobe reserves the right to
>>>>> download and install additional Content Protection software on the
>>>>> user's PC.
>>>> Not like anyone will actually *read* the license before adding it to
>>>> their accept group, but if they did this would indeed be an importan=
t
>>>> thing of which users should be aware.
>>> I defend it is our job to warn users about this kind of details. To m=
e
>>> it sounds that a einfo at post-build phase would do the job, what do=20
>>> you
>>> guys think?

Though I am not opposed to adding a warning, I think the license mask is=20
sufficient. If users demonstrate their indifference by setting=20
ACCEPT_LICENSE=3D"*" or adding AdobeFlash-10.1 without reading the=20
license, then I somehow doubt that elog messages will have an effect.
>> Definitely yes! This is a very dangerous snippet in Adobe's license=20
>> which
>> should be pretty clearly pointed at to every user.
>>
>
> Could that also include a alternative to adobe? If there is one.

There are three open-source flash browser plugins in portage:
- swfdec: development seems to have stalled
- gnash: I have received mixed reports about the stability of the=20
current version. The next release will include VA-API support and other=20
improvements.
- lightspark: a recent effort which is in its early stages and still=20
incomplete in many ways (eg. audio support is planned for 0.4.2)

None of them I consider good enough to replace adobe-flash for the=20
average user.


Regards,
Ch=C3=AD-Thanh Christopher Nguy=E1=BB=85n
 
Old 06-17-2010, 11:10 PM
Marek Otahal
 
Default New Google Group for discussion and notices on Arch security.

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 )
 
Old 06-17-2010, 11:12 PM
Burlynn Corlew Jr
 
Default New Google Group for discussion and notices on Arch security.

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.
 
Old 06-18-2010, 12:33 AM
C Anthony Risinger
 
Default New Google Group for discussion and notices on Arch security.

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.
 
Old 06-18-2010, 02:48 AM
"Jeffrey 'jf' Lim"
 
Default New Google Group for discussion and notices on Arch security.

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
 
Old 06-18-2010, 05:25 AM
Andres P
 
Default New Google Group for discussion and notices on Arch security.

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
 
Old 06-18-2010, 05:48 AM
"Jeffrey 'jf' Lim"
 
Default New Google Group for discussion and notices on Arch security.

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
 
Old 06-18-2010, 06:33 AM
Andres P
 
Default New Google Group for discussion and notices on Arch security.

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
 
Old 06-18-2010, 07:01 AM
"Jeffrey 'jf' Lim"
 
Default New Google Group for discussion and notices on Arch security.

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
>
 

Thread Tools




All times are GMT. The time now is 09:13 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org