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, 06:57 PM
Ananda Samaddar
 
Default New Google Group for discussion and notices on Arch security.

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
 
Old 06-17-2010, 10:06 PM
"Jeroen Op 't Eynde"
 
Default New Google Group for discussion and notices on Arch security.

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
 
Old 06-17-2010, 10:58 PM
"Jeroen Op 't Eynde"
 
Default New Google Group for discussion and notices on Arch security.

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
 
Old 06-17-2010, 11:00 PM
Ng Oon-Ee
 
Default New Google Group for discussion and notices on Arch security.

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.
 
Old 06-17-2010, 11:03 PM
"Jeroen Op 't Eynde"
 
Default New Google Group for discussion and notices on Arch security.

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
 

Thread Tools




All times are GMT. The time now is 07:16 AM.

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