On Monday 30 November 2009 22:40:07 Hal Murray wrote:
g...@czarc.net said:
...
A written description of the security policy is a must!
...
Is the idea of a single one-size-fits-all security policy reasonable? I
think Fedora has a broad range of users.
No. Initially, I recommend
On Monday 30 November 2009 18:16:50 Adam Williamson wrote:
On Mon, 2009-11-30 at 15:17 -0500, Eric Christensen wrote:
Gene,
(Ahh... someone with a similar background...)
So the biggest question, to me, is to what standard do we start?
There are plenty to choose from from DISA to NIST.
On Mon, Nov 30, 2009 at 22:40, Hal Murray hmur...@megapathdsl.net wrote:
g...@czarc.net said:
...
A written description of the security policy is a must!
...
Is the idea of a single one-size-fits-all security policy reasonable? I
think Fedora has a broad range of users.
Probably not
On Tue, Dec 1, 2009 at 12:47, Gene Czarcinski g...@czarc.net wrote:
On Monday 30 November 2009 18:16:50 Adam Williamson wrote:
Where I'm currently at is that I'm going to talk to some Red Hat /
Fedora security folks about the issues raised in all the discussions
about this, including this
On Tue, 2009-12-01 at 12:47 -0500, Gene Czarcinski wrote:
I suspect that most commercial and government customers will be interested in
Red Hat Enterprise Linux rather than Fedora. But, Fedora is the technology
base on which future Red Hat Enterprise Linux releases are built. The better
On Tuesday 01 December 2009 13:56:51 Adam Williamson wrote:
On Tue, 2009-12-01 at 12:47 -0500, Gene Czarcinski wrote:
I suspect that most commercial and government customers will be
interested in Red Hat Enterprise Linux rather than Fedora. But, Fedora
is the technology base on which
On Tuesday 01 December 2009 13:04:02 Eric Christensen wrote:
On Tue, Dec 1, 2009 at 12:47, Gene Czarcinski g...@czarc.net wrote:
On Monday 30 November 2009 18:16:50 Adam Williamson wrote:
Where I'm currently at is that I'm going to talk to some Red Hat /
Fedora security folks about
Although I have read all of the messages on this thread as of the date/time of
this message, I am replying to this first message with all of my comments.
My background: I am currently retired but a few years ago I was still being
paid the big bucks for working on computer security and security
On Mon, Nov 30, 2009 at 15:09, Gene Czarcinski g...@czarc.net wrote:
Although I have read all of the messages on this thread as of the date/time
of
this message, I am replying to this first message with all of my comments.
My background: I am currently retired but a few years ago I was still
Gene Czarcinski (g...@czarc.net) said:
Keep it simple (KISS) for the initial attempt. It will grow more complicated
all by itself as time passes.
BTW, the security policy should assume that a grub password is in use so that
a user cannot do something like disabling selinux by editing the
On Mon, Nov 23, 2009 at 06:10:59PM -0800, Adam Williamson wrote:
On Mon, 2009-11-23 at 19:38 -0500, Matthias Clasen wrote:
How that translates in packages and defaults is not really the most
important part, but the plan is to have strict package defaults + a
policy package that makes
I don't want to ship a desktop that doesn't let the user do useful
things.
And you can ship a desktop SPIN that way. But the base pkgs should
not install with an insecure set of choices.
if you want the spin to have a post-scriptlet which allows more
things, then that's the choice of the
Gregory Maxwell (gmaxw...@gmail.com) said:
If some some spin decided to make every user run as root, ship with no
firewalling,
have password-less accounts, or have insecure services enabled by
default, etc.
You mean Sugar as configured on the XO? (It has passwordless user,
who can su without
On Tue, 2009-11-24 at 13:28 -0500, Bill Nottingham wrote:
I don't want to ship a desktop that doesn't let the user do useful
things.
And you can ship a desktop SPIN that way. But the base pkgs should
not install with an insecure set of choices.
if you want the spin to have a
On Tue, 24 Nov 2009, Bill Nottingham wrote:
I don't want to ship a desktop that doesn't let the user do useful
things.
And you can ship a desktop SPIN that way. But the base pkgs should
not install with an insecure set of choices.
if you want the spin to have a post-scriptlet which allows
On Tue, 2009-11-24 at 10:44 -0800, Adam Williamson wrote:
As I noted somewhat flippantly in another thread, this comes with the
problem that, theoretically, a user who has the privileges to install
packages at a relaxed security level could arbitrarily raise the
security level of the system
On Tue, Nov 24, 2009 at 01:29:11PM -0500, Bill Nottingham wrote:
You mean Sugar as configured on the XO? (It has passwordless user,
who can su without a password.)
Annnd if you set a root password, stuff breaks.
--
Matthew Miller mat...@mattdm.org
Senior Systems Architect
Chris Ball (c...@laptop.org) said:
If some some spin decided to make every user run as root, ship
with no firewalling, have password-less accounts, or have
insecure services enabled by default, etc.
You mean Sugar as configured on the XO? (It has passwordless
user, who
On Tue, 2009-11-24 at 15:34 -0500, Bill Nottingham wrote:
Chris Ball (c...@laptop.org) said:
If some some spin decided to make every user run as root, ship
with no firewalling, have password-less accounts, or have
insecure services enabled by default, etc.
You mean
Adam Williamson (awill...@redhat.com) said:
It's true, but note that the XO software is technically a Remix
rather than a Spin, so there aren't any technical requirements
on it to satisfy the use of the Fedora mark. (I think I'd agree
with Greg's point regarding official Fedora
Hi, everyone. I'm sending this email as a result of a discussion in the
Fedora QA meeting this morning. You can find a log of the meeting here:
http://meetbot.fedoraproject.org/fedora-meeting/2009-11-23/fedora-meeting.2009-11-23-16.00.log.html
the discussion takes place from 16:14:09 onwards.
On Mon, 2009-11-23 at 14:08 -0800, Adam Williamson wrote:
This list of packages
would be what the QA team would test with regard to the security policy.
We also believe there ought to be a process for maintaining this list,
and additions to the packaging guidelines for any new package which
On Mon, 2009-11-23 at 14:08 -0800, Adam Williamson wrote:
It's not QA's role to define exactly what the security policy should
look like or what it should cover, but from the point of view of
testing, what we really need are concrete requirements. The policy does
not have to be immediately
On Mon, 23 Nov 2009, Matthias Clasen wrote:
On Mon, 2009-11-23 at 14:08 -0800, Adam Williamson wrote:
It's not QA's role to define exactly what the security policy should
look like or what it should cover, but from the point of view of
testing, what we really need are concrete requirements.
On Mon, 2009-11-23 at 17:55 -0500, Matthias Clasen wrote:
On Mon, 2009-11-23 at 14:08 -0800, Adam Williamson wrote:
It's not QA's role to define exactly what the security policy should
look like or what it should cover, but from the point of view of
testing, what we really need are
On Mon, Nov 23, 2009 at 05:55:15PM -0500, Matthias Clasen wrote:
On Mon, 2009-11-23 at 14:08 -0800, Adam Williamson wrote:
It's not QA's role to define exactly what the security policy should
look like or what it should cover, but from the point of view of
testing, what we really need are
On 11/23/2009 10:55 PM, Matthias Clasen wrote:
On Mon, 2009-11-23 at 14:08 -0800, Adam Williamson wrote:
It's not QA's role to define exactly what the security policy should
look like or what it should cover, but from the point of view of
testing, what we really need are concrete
Once upon a time, Adam Williamson awill...@redhat.com said:
It's not QA's role to define exactly what the security policy should
look like or what it should cover, but from the point of view of
testing, what we really need are concrete requirements. The policy does
not have to be immediately
On Mon, 2009-11-23 at 18:31 -0500, Seth Vidal wrote:
Otherwise we open ourselves up to a less-secure-by-default posture in an
average install.
We've been in that position in the past and it is not a favorable place to
be.
We should just avoid to sink tons of QA resources in verifying
On Mon, 23 Nov 2009, Matthias Clasen wrote:
On Mon, 2009-11-23 at 18:31 -0500, Seth Vidal wrote:
Otherwise we open ourselves up to a less-secure-by-default posture in an
average install.
We've been in that position in the past and it is not a favorable place to
be.
We should just avoid
On Mon, 2009-11-23 at 19:36 -0500, Seth Vidal wrote:
On Mon, 23 Nov 2009, Matthias Clasen wrote:
On Mon, 2009-11-23 at 18:31 -0500, Seth Vidal wrote:
Otherwise we open ourselves up to a less-secure-by-default posture in an
average install.
We've been in that position in the past
On Mon, 23 Nov 2009, Matthias Clasen wrote:
I don't want to ship a desktop that doesn't let the user do useful
things.
And you can ship a desktop SPIN that way. But the base pkgs should not
install with an insecure set of choices.
if you want the spin to have a post-scriptlet which
On Mon, 2009-11-23 at 19:54 -0500, Seth Vidal wrote:
We should not be forcing the choices for the desktop spin on everyone who
installs a pkg in the distribution.
Sure, I agree.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
On Mon, 2009-11-23 at 14:33 -0800, Jesse Keating wrote:
On Mon, 2009-11-23 at 14:08 -0800, Adam Williamson wrote:
This list of packages
would be what the QA team would test with regard to the security policy.
We also believe there ought to be a process for maintaining this list,
and
On Mon, 2009-11-23 at 18:16 -0600, Chris Adams wrote:
Once upon a time, Adam Williamson awill...@redhat.com said:
It's not QA's role to define exactly what the security policy should
look like or what it should cover, but from the point of view of
testing, what we really need are concrete
On Mon, Nov 23, 2009 at 6:39 PM, Jesse Keating jkeat...@redhat.com wrote:
Sure, I don't disagree, but I think we can take spots list and use it
for the 'guest account'. Then you start picking things off the list as
you move up the stack to 'university computer lab user (is that really
much
On Mon, 2009-11-23 at 19:38 -0500, Matthias Clasen wrote:
How that translates in packages and defaults is not really the most
important part, but the plan is to have strict package defaults + a
policy package that makes things work.
The important part is that we QA the combination, not
On Mon, Nov 23, 2009 at 9:10 PM, Adam Williamson awill...@redhat.com wrote:
Having said that - is everyone agreeing that it's fine for each spin SIG
to be entirely in charge of defining and implementing security policy
[snip]
Different spins having different security makes sense, especially if
On Mon, 2009-11-23 at 18:10 -0800, Adam Williamson wrote:
On Mon, 2009-11-23 at 19:38 -0500, Matthias Clasen wrote:
How that translates in packages and defaults is not really the most
important part, but the plan is to have strict package defaults + a
policy package that makes things
39 matches
Mail list logo
