On Tuesday 01 December 2009 13:04:02 Eric Christensen wrote:
> On Tue, Dec 1, 2009 at 12:47, Gene Czarcinski 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 i
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 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 Tue, Dec 1, 2009 at 12:47, Gene Czarcinski 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 thread,
On Mon, Nov 30, 2009 at 22:40, 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.
>
Probably not but there are s
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
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 r
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. I, personally,
> find the NSA's "Guide to the Secure Config
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
On Mon, Nov 30, 2009 at 15:09, Gene Czarcinski 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 being
> p
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 a
Hi,
> Yes, but how often have we touted XO, Sugar, et. al. as being
> 'based on Fedora' over the past 4 years? Heck, you could argue
> it's gotten more press than some of our official spins.
Right, but "based on Fedora" is fine: it correctly conveys the
impression that we took a pristin
On Tue, 2009-11-24 at 15:44 -0500, Bill Nottingham wrote:
> 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
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 offici
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.
> >
> >
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
>
Hi,
> 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 passwordle
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
Senior Systems Architect
Cyberinfrastructure Labs / Instruc
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 syste
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 m
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 t
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 with
> >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 choi
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 mak
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 thin
On Mon, Nov 23, 2009 at 9:10 PM, Adam Williamson 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 the
differences ar
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 6:39 PM, Jesse Keating 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 different from gue
On Mon, 2009-11-23 at 18:16 -0600, Chris Adams wrote:
> Once upon a time, Adam Williamson 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.
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,
> > a
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
https://www.redhat.com/mailman/listinfo/fedora
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 allows
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 posi
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 t
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 verify
Once upon a time, Adam Williamson 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 comprehensive - t
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 requiremen
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 n
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, 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 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, 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
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.
We
43 matches
Mail list logo
