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


 
 
LinkBack Thread Tools
 
Old 05-22-2008, 12:54 AM
Björn Persson
 
Default

Will Woods wrote:
> Preupgrade is currently designed to be exactly as secure as an anaconda
> http install. No less, no more.

But it's not being marketed as an alternative to an Anaconda HTTP install with
less downtime as the only improvement. It's being marketed as a safer
alternative to a live upgrade with Yum, and as a faster, more convenient and
less bandwidth-wasting alternative to downloading and burning DVD images. See
this article for example:

http://www.redhatmagazine.com/2008/04/15/interview-fedora-developers-seth-vidal-and-will-woods/

The article talks a lot about how Preupgrade is better than both a Yum upgrade
and a DVD-based upgrade, but says very little about network-based Anaconda
upgrades, and it's completely silent about the security aspect. Here's a
quote from the article:

"So you can upgrade with the convenience and bandwidth savings of a live
upgrade, but without the risky craziness inherent therein."

Yeah, it avoids the risky craziness inherent in a Yum upgrade but adds instead
the crazy riskiness inherent in an HTTP-based Anaconda upgrade. That's no
improvement in my book. No matter what the risks with a Yum upgrade are,
getting intruders in my computer is worse.

> Nothing's *missing*. There just aren't any signatures to check for the
> boot images, and there never have been.

For several years now, all my boot images have been included in ISO images.
Those ISO images have been accompanied by checksum files, and those checksum
files have been cryptographically signed. I always verify the signature and
the checksums, and when they're verified correctly I know that all the files
in the ISO image are clean, including the boot images.

Generating detached signatures for the boot images and putting them in the
directory where the images are published would take at most five minutes of
manual work for each release.

> Furthermore anaconda doesn't check the gpg signatures of packages it
> downloads and installs during http installs. Never has. That's bug #998.
> (Yes, #998. Not a typo. See https://bugzilla.redhat.com/998)

Would you like to guess why I never do network-based installs except from my
own server directly attached with a crossover cable?

Björn Persson

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 05-22-2008, 01:45 AM
max
 
Default

Björn Persson wrote:

Will Woods wrote:

Preupgrade is currently designed to be exactly as secure as an anaconda
http install. No less, no more.


But it's not being marketed as an alternative to an Anaconda HTTP install with
less downtime as the only improvement. It's being marketed as a safer
alternative to a live upgrade with Yum, and as a faster, more convenient and
less bandwidth-wasting alternative to downloading and burning DVD images. See
this article for example:


http://www.redhatmagazine.com/2008/04/15/interview-fedora-developers-seth-vidal-and-will-woods/

The article talks a lot about how Preupgrade is better than both a Yum upgrade
and a DVD-based upgrade, but says very little about network-based Anaconda
upgrades, and it's completely silent about the security aspect. Here's a
quote from the article:


"So you can upgrade with the convenience and bandwidth savings of a live
upgrade, but without the risky craziness inherent therein."


Yeah, it avoids the risky craziness inherent in a Yum upgrade but adds instead
the crazy riskiness inherent in an HTTP-based Anaconda upgrade. That's no
improvement in my book. No matter what the risks with a Yum upgrade are,
getting intruders in my computer is worse.



Nothing's *missing*. There just aren't any signatures to check for the
boot images, and there never have been.


For several years now, all my boot images have been included in ISO images.
Those ISO images have been accompanied by checksum files, and those checksum
files have been cryptographically signed. I always verify the signature and
the checksums, and when they're verified correctly I know that all the files
in the ISO image are clean, including the boot images.


Generating detached signatures for the boot images and putting them in the
directory where the images are published would take at most five minutes of
manual work for each release.



Furthermore anaconda doesn't check the gpg signatures of packages it
downloads and installs during http installs. Never has. That's bug #998.
(Yes, #998. Not a typo. See https://bugzilla.redhat.com/998)


Would you like to guess why I never do network-based installs except from my
own server directly attached with a crossover cable?


Björn Persson

First my thanks to Bjorn for taking the time to start this discussion.
Then my piece, after which I will try like hell to leave this alone.
I am glad at least that the "preupgrade is still in testing" argument
was never brought up or the "your automatically a guinea pig if you get
things from the testing repo". All that aside I for one feel that if the
Fedora Community is going to continue to thrive and grow then security
has to be dealt with openly. I have in the past tried to broach the
security issue without much success. Everyone is afraid to talk about
it, instead I have seen suggestions, from some, that these things
shouldn't be discussed openly for fear that crackers will get ideas.
Security by obscurity is not real security, its just purposely pulling
the wool over your own eyes. If the time isn't taken to properly
consider these things in the planning phase then what are the odds that
it will ever be dealt with properly? Who will you blame when your box
gets compromised? How many will look in the mirror first when the time
comes? How many of us have the stones to that honest with ourselves? A
while back I posted a link to an article that I found while going over
Dan Walsh's live journal, it was titled : The Six Dumbest Ideas in
Computer Security. The article is itself a few years old and most of the
dumb ideas much older than that, frankly I am surprised by how many of
these dumb ideas are still around , not necessarily among the Fedora
Community specifically but out there where I work, amongst these small
businesses that I do work for on occassion, most especially but not
surprisingly amongst the home pc users, largely running M$ sure but even
so I have seen this ignorance extend to system admins with many years of
experience. People seem to just put their security in the hands of some
software engineer they have never met and accept whatever half baked
piece of crap gets marketed from week to week. I wonder what it says
about a community that the issue cannot be raised without it
degenerating in to some mindless flame war, that a positive and useful
discussion cannot take place on the bleeding edge of software amongst a
community that is supposed to be leading the way for FOSS. I've said my
piece, torch me in effigy if you must, start lobbing the flame grenades
at me if you need a target, blame me if you like for all the ills of the
world, it ultimately won't change the fact that many of us shirk our
responsibilty to Fedora and Redhat.
I have an operating system, completely free, it costs me nothing. All i
hear is whining about the video drivers, pulseaudio. "I am going to
Ubuntu" because i can't get my palm pilot to work or my mp3 codec isn't
included. There is always my personal favorite "I am turning SELinux
off, its too hard, it sucks, my flash doesn't work". The Adobe flash is
a gaping security hole in every computer across this planet and people
line up to get screwed by it. We've been given a gift, a precious thing,
the freedom to define our experience and instead of helping improve it
all we do is complain that it doesn't measure up to our broken standard.


--
On the eighth day he said "There shall be no rest for the weary."

On the ninth day he farted, and it smelled like sulphur ;^)

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 05-22-2008, 12:14 PM
Ralf Mardorf
 
Default

-------- Original Message --------
Subject: Re: [64studio-users] setting up a phenom machine
Date: Thu, 22 May 2008 14:13:54 +0200
From: Ralf Mardorf <ralf.mardorf@alice-dsl.net>
To: Dragan Noveski <perodog@gmx.net>
References: <48354672.2070200@gmx.net>



> cpu: amd phenom9850
>
> does anyone can say anything about the phenom cpu?
>

I can't, but you should be careful with buying to modern hardware.

My AMD Athlon X2 BE-2350 on an ASUS M2A-VM HDMI seems to be fine with
64studio 2.1rc. 64bit, but I've heard about trouble with Windows and
Memtest isn't fine with my RAMs, 64studio seems to be fine with the RAMs.

It seems to be, that AMD Dual-Cores are fine with 64bit Linux, but new
hardware like the ASUS M2A-VM HDMI might be critical.

Perhaps it won't be wise to buy a Quad Core?! You should search several
forums.

Cheers,
Ralf


_______________________________________________
64studio-users mailing list
64studio-users@64studio.com
http://lists.64studio.com/mailman/listinfo/64studio-users
 
Old 05-22-2008, 02:01 PM
"Cybe R. Wizard"
 
Default

Mario Vukelic <mario.vukelic@dantian.org> said:
> On Wed, 2008-05-21 at 01:20 -0500, Cybe R. Wizard wrote:
> > Beware, this is /exactly/ what killed off the Libranet linux mailing
> > list.
>
> Wasn't the reason for the death of the Libranet list the death of
> Libranet as such?

Well, the corpse /did/ lurch on until the demise of the distro but, no,
its death resulted from one of the head guys *cough*the son*cough*
beginning to censor what he didn't like. In fact, several of the real
helpers created an off-grid list which still lives today. They
graciously allowed me to join.
>
> Anyway, if all the knowledgeable guys [1] should become unhappy
> because every time they post an offtopic message, they are bitched
> at, that can't be good for the list either.

Another cause of Libranet's list demise. The knowledgeable left.
>
> I mean, I posted around five thousand messages to this list trying to
> help people, and very rarely a wildly offtopic one - it happens. I
> rarely ever get a "thanks" from the people I helped, and I generally
> don't mind. As soon as I post an even mildly offtopic one, someone is
> always quick to complain, and that just might make me mind at some
> point.
>
BTW, thanks for the help you've given me on several occasions. Several
times you've opened my eyes, even when I haven't been participating in
the discussion.
As for OT, I don't mind it, am mostly interested in the discussions and
think they do more good than harm.
>
> > Next the frequent contributors will start thinking they should
> > have the ability to have political leanings in their .sigs!
> > Heavens, what next?
>
> If you take a look at the the sigs that are actually posted, I think
> you will find that the regulars have usually none or harmless ones.
> The sigs that I must try hard not to complain about usually don't
> come from the frequent posters. And you know what, I complained once
> on the list and once in private; given what I have to read in those
> sigs, I think I'm doing an amazing job and I just think other
> people could cut some slack, too.

Yes, you are doing an amazing job. I admire your restraint. ;-]

Have I mentioned that I've gotten off-list flak from a couple of folks
for /my/ .sig? Amazingly, they thought of it as sexual!

Cybe R. Wizard -some people just don't get jokes
--
Nice computers don't go down.
Larry Niven, Steven Barnes
"The Barsoom Project"

--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 05-22-2008, 02:18 PM
Florian Diesch
 
Default

Steve Lamb <grey@dmiyu.org> wrote:

> Florian Diesch wrote:
>> The nice thing about text files is that there are so many tools to
>> work with them. Shouldn't be much of a problem to integrate them in a
>> modern vi clone like vim.
>
> Esp. if one uses one of the many vims with an embedded scripting engine.
> vim-python with built in mercurial, anyone?

No thanks. It's Emacs land here. ;-)


Florian
--
<http://www.florian-diesch.de/>
-----------------------------------------------------------------------
** Hi! I'm a signature virus! Copy me into your signature, please! **
-----------------------------------------------------------------------

--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 05-22-2008, 03:13 PM
Florian Diesch
 
Default

"Steve Lamb" <grey@dmiyu.org> wrote:

> On Wed, May 21, 2008 7:48 am, Derek Broughton wrote:
>> For instance, it's inherent in the design of
>> Ubuntu that the first user set up on the system has sudo access. Isn't it
>> much nicer that Ubuntu configures /etc/sudoers for us, than then asking us
>> to set it up ourselves (as if we even could...)?
>
> Nope. Because sudo certainly isn't needed on a single-user system. The
> imposition of sudo on a single-user system is what requires the default
> of the first user being injected into the sudoers file with ALL ALL
> access.

If you don't want to work as root all the time you really want some
simple way to run a command as root. Using sudo instead of su makes
it a little bit easier as you don't have to remember two passwords.

IMHO that's a good choice for desktop boxes, even if there's only one
user.


> Even worse on a multi-user system where one would want sudo chances are
> the person who's installing the OS isn't going to be the only one you
> want to give sudo access to. Therefore it'll have to be edited by
> someone competent anyway.

By default Ubuntu gives sudo access to everyone in the admin group. No
editing needed in your example.



Florian
--
<http://www.florian-diesch.de/>
-----------------------------------------------------------------------
** Hi! I'm a signature virus! Copy me into your signature, please! **
-----------------------------------------------------------------------

--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 05-22-2008, 03:39 PM
Florian Diesch
 
Default

Derek Broughton <news@pointerstop.ca> wrote:

> Mario Vukelic wrote:
>
>> On Tue, 2008-05-20 at 11:02 -0300, Derek Broughton wrote:
>>>
>> A real GUI
>> tool that protects the naive user from stupidity is guaranteed to impede
>> the knowledgeable user by "knowing better".
>
> How so? You keep making this statement, but since the config file has a
> fixed grammar, how is it possible for a knowledgeable user to "know
> better"?

Grammars can be quite complex. From my experience GUIs tend to either
support only a subset then or are difficult to use.


> Off the top of my head, configuration files consist of the following sorts
> of options:
>
> - multiple choice
> - integer
> - text (sometimes with content rules)
> - if A then B

They often have some kind of a hierarchical structure where some
groups of options can be repeated in some places. Creating a clear GUI
that supports very deep hierarchies is difficult. Nost GUI designers
fail here.


Some config languages are turing-complete, sendmail and Emacs are well
known examples here. To have a GUI explore their full possibilities
needs a GUI for writing programs.



Florian
--
<http://www.florian-diesch.de/>
-----------------------------------------------------------------------
** Hi! I'm a signature virus! Copy me into your signature, please! **
-----------------------------------------------------------------------

--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 05-22-2008, 04:00 PM
Florian Diesch
 
Default

Derek Broughton <news@pointerstop.ca> wrote:

> Mario Vukelic wrote:
>
>> On Tue, 2008-05-20 at 15:32 -0300, Derek Broughton wrote:
>
>> Or maybe
>> you make it look much simpler than it is by conflating nearly everything
>> into "text".
>
> Agreed. The point being that those other options _are_ simplistic.
>
>> May I offer procmailrc as an example for something that
>> would probably be impossible to implement with a GUI configurator that
>> should also check that the file really does what the user intended:
>> http://www.gsp.com/cgi-bin/man.cgi?section=5&topic=procmailrc
>
> Well, I'm not going to write the config tool right now (or probably ever - I
> never liked procmail - though I was working on one for maildrop), but start
> at the beginning - sooner or later every recipe has to deliver mail to a
> file, pipe or program, or to another user. It's simple to check that the
> file/pipe/program exists.

Only if you are working ion the mail server where the mails are
delivered. Usually you are not.

> Validating an email address is harder - do you
> simply check that the format is good, or actually test SMTP? Neither one
> is impossible, though.

But it's frustrating to see how man programs fail when doing syntax
checks on email addresses.

Testing by SMTP doesn't give you much as if an address is accepted by
some server that doesn't necessarily mean it gets delivered. Maybe
you get a bounce message a few minutes (or hours or days) later.


> Now, I can conceive of a situation where I might
> actually forward to an invalid SMTP address intentionally (expecting the
> address to be created shortly) but then it's a matter of what procmail
> would do with such an address when actually running - if procmail will
> retry, it's just a warning, if procmail would drop it, it's an error.

procmail just hands to mail to your MTA to send it, it doesn'r know
anything about SMTP itself.


>> It's not so much about valid key=value pairs, it is about legitimate
>> combinations of values.
>
> The "If A then B" conditions. In your example, procmail already checks
> those, so why can't a config tool for procmailrc do the same?

A bit more advanced procmail recipes usually contain some amount of
shell code (that may contain inlined code for other interpreters). How
will your GUI handle this?


Florian
--
<http://www.florian-diesch.de/>
-----------------------------------------------------------------------
** Hi! I'm a signature virus! Copy me into your signature, please! **
-----------------------------------------------------------------------

--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 05-22-2008, 04:48 PM
"Steve Lamb"
 
Default

On Thu, May 22, 2008 8:13 am, Florian Diesch wrote:
> "Steve Lamb" <grey@dmiyu.org> wrote:
>> Nope. Because sudo certainly isn't needed on a single-user system.

> If you don't want to work as root all the time you really want some
> simple way to run a command as root. Using sudo instead of su makes
> it a little bit easier as you don't have to remember two passwords.

There isn't many times that I want to run *a* command as root. Often I
want to run a *sequence* of commands which require the elevated
privileges of root to remain for the entire sequence. sudoing to root
and suing to root is functionally identical thus sudo is not needed.

Also the matter of passwords is moot. One can simply set the root
password to their normal account password and achieve the same effect.
Again, functionally identical to sudo complete with the resulting weaker
security.

> By default Ubuntu gives sudo access to everyone in the admin group. No
> editing needed in your example.

Presumes everyone is going to be in the admin group. The point of sudo
is limiting elevated privileges to specific commands. Since that is
going to be unique per user editing will be required.

Look, I'm not saying that sudo should be removed or that the Ubuntu use
of sudo isn't convenient in some cases. I am just pointing out that as
an example by Derek of a configuration tool "doing the right thing" it
is spurious precisely because it isn't needed in the vast majority of
installs where such niceties would be "needed".

--
Steve Lamb


--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 05-22-2008, 06:42 PM
Derek Broughton
 
Default

Avi Greenbury wrote:

>> Do you actually intentionally make "stupid" mistakes that can never
>> possibly
>> work? That's what a config tool should prevent. When a config value
>> needs to be a domain name, it may be desirable to permit domains that
>> can't currently be resolved, but it's never going to desirable to allow
>> you to enter a domain that could never be registered.
>
> It depends on your interpretation of 'stupid' and 'never', I suppose.
> What kind of domain that could never be registered, and that no-one
> will ever want in their configuration, do you have in mind?

Anything that's syntactically incorrect.

> If you have, as you say, an idiot who can not and will not learn, and
> they should be prevented from screwing up the servers, the easiest way
> to accomplish that is to not let them anywhere near them, and let
> someone who has learnt do the configuration.

And I'm being accused of not living in the real world. The world is full of
pointy-haired bosses who couldn't care less that they've put the least
technically competent person in charge of their web server...
--
derek


--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 

Thread Tools




All times are GMT. The time now is 03:42 AM.

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