<quote>
Hole in Linux kernel provides root rights
17 September 2010

A vulnerability in the 32-bit compatibility mode of the current Linux kernel 
(and previous versions) for 64-bit systems can be exploited to escalate 
privileges. For instance, attackers can break into a system and exploit a 
hole in the web server to get complete root (also known as superuser) rights 
or permissions for a victim's system.

The kernel developers have remedied the flaw in the repository, and Linux 
distributors will probably soon publish new kernels to close the hole. 
Until then, switching off 32-bit ELF support solves the problem if you can 
do without this function.

Hawkes says the vulnerability was discovered and remedied back in 2007, but 
at some point in 2008 kernel developers apparently removed the patch, 
reintroducing the vulnerability. The older exploit apparently only needed 
slight modifications to work with the new hole.
</quote>

 

<http://secunia.com/advisories/41202/>

Secunia Advisory   SA41202      
Release Date       2010-09-02
Criticality level  Highly critical
Impact             System access
Where              From remote

Solution
Do not open untrusted files

On Sat, 18 Sep 2010 08:47:26 -0400, "Ezekiel" <Me@Not-there.com>
wrote:

>
><quote>
>Hole in Linux kernel provides root rights
>17 September 2010
>
>A vulnerability in the 32-bit compatibility mode of the current Linux kernel 
>(and previous versions) for 64-bit systems can be exploited to escalate 
>privileges. For instance, attackers can break into a system and exploit a 
>hole in the web server to get complete root (also known as superuser) rights 
>or permissions for a victim's system.
>
>The kernel developers have remedied the flaw in the repository, and Linux 
>distributors will probably soon publish new kernels to close the hole. 
>Until then, switching off 32-bit ELF support solves the problem if you can 
>do without this function.
>
>Hawkes says the vulnerability was discovered and remedied back in 2007, but 
>at some point in 2008 kernel developers apparently removed the patch, 
>reintroducing the vulnerability. The older exploit apparently only needed 
>slight modifications to work with the new hole.
></quote>


Let the denial begin......
 
-- 
Moshe Goldfarb
Collector of soaps from around the globe.
Linux...Disappointing users for 19 years.
Linux::It's free when your time has no value.
See Liarmutt in action http://www.youtube.com/watch?v=SazBzvQ0ZAM

Hardon posted this message in ROT13 encoding:

> <http://secunia.com/advisories/41202/>
>
> Secunia Advisory   SA41202      
> Release Date       2010-09-02
> Criticality level  Highly critical
> Impact             System access
> Where              From remote
>
> Solution
> Do not open untrusted files

*chuckle*

   The vulnerability is caused due to the GraphEdit application loading
   libraries (e.g. measure.dll) in an insecure manner. This can be exploited
   to load arbitrary libraries by tricking a user into e.g. opening a Filter
   Graph (.grf) file located on a remote WebDAV or SMB share.

-- 
He who wonders discovers that this in itself is wonder.
		-- M. C. Escher

Moshe Goldfarb <moshe_golfarb@yahoo.com> writes:

> On Sat, 18 Sep 2010 08:47:26 -0400, "Ezekiel" <Me@Not-there.com>
> wrote:
>
>>
>><quote>
>>Hole in Linux kernel provides root rights
>>17 September 2010
>>
>>A vulnerability in the 32-bit compatibility mode of the current Linux kernel 
>>(and previous versions) for 64-bit systems can be exploited to escalate 
>>privileges. For instance, attackers can break into a system and exploit a 
>>hole in the web server to get complete root (also known as superuser) rights 
>>or permissions for a victim's system.
>>
>>The kernel developers have remedied the flaw in the repository, and Linux 
>>distributors will probably soon publish new kernels to close the hole. 
>>Until then, switching off 32-bit ELF support solves the problem if you can 
>>do without this function.
>>
>>Hawkes says the vulnerability was discovered and remedied back in 2007, but 
>>at some point in 2008 kernel developers apparently removed the patch, 
>>reintroducing the vulnerability. The older exploit apparently only needed 
>>slight modifications to work with the new hole.
>></quote>
>
> Let the denial begin......

And the incompetent "fanboy" sysadmin claims of "up time" reduce .....

Verily I say unto thee, that Chris Ahlstrom spake thusly:
> Hardon posted this message in ROT13 encoding:
> 
>> <http://secunia.com/advisories/41202/>
>> 
>> Secunia Advisory   SA41202
>> Release Date       2010-09-02
>> Criticality level  Highly critical
>> Impact             System access
>> Where              From remote
>> 
>> Solution
>> Do not open untrusted files
> 
> *chuckle*
> 
> The vulnerability is caused due to the GraphEdit application loading 
> libraries (e.g. measure.dll) in an insecure manner. This can be
> exploited to load arbitrary libraries by tricking a user into e.g.
> opening a Filter Graph (.grf) file located on a remote WebDAV or SMB
> share.

The vulnerability is caused by a bunch of unethical investment brokers
masquerading as software developers releasing a steaming pile of slop.

-- 
K.
http://slated.org

..----
| You can't make an omelet without building some bridges
| ... but don't count your bridges until they've hatched
`----

Fedora release 8 (Werewolf) on sky, running kernel 2.6.31.5
 20:21:49 up 14 days,  3:40,  0 users,  load average: 0.00, 0.01, 0.00

On Sep 18, 8:47=A0am, "Ezekiel" <M...@Not-there.com> wrote:
> <quote>
> Hole in Linux kernel provides root rights
> 17 September 2010

> A vulnerability in the 32-bit compatibility mode of the current Linux ker=
nel
> (and previous versions) for 64-bit systems can be exploited to escalate
> privileges. For instance, attackers can break into a system and exploit a
> hole in the web server to get complete root (also known as superuser) rig=
hts
> or permissions for a victim's system.

How many hackers have successfully exploited this vulnerability?
How many Linux computers have been successfully hacked?
Are there any security measures you have to disable in order to get
the hack to work?
Are there any special applications or libraries that must be loaded?
Are there any special configuration changes required to successfully
exploit a PC.

> The kernel developers have remedied the flaw in the repository, and Linux
> distributors will probably soon publish new kernels to close the hole.

This wouldn't be the first time that a kernel patch for a theoretical
vulnerability that could only be exploited by very carefully using
root access to mis-configure an application or service.

> Until then, switching off 32-bit ELF support solves the problem if you ca=
n
> do without this function.

ELF, that's been around a very long time.  It's normally used for UNIX
on Intel, but Linux can also run ELF programs if the ELF libraries are
installed.

http://en.wikipedia.org/wiki/Executable_and_Linkable_Format

> Hawkes says the vulnerability was discovered and remedied back in 2007, b=
ut
> at some point in 2008 kernel developers apparently removed the patch,

So this vulnerability has been around since 2008 and it hasn't
resulted in the massive crashes of hundreds of thousands of Linux
servers?  Must not be that vulnerable.

> reintroducing the vulnerability.

> The older exploit apparently only needed
> slight modifications to work with the new hole.

So slight modifications were needed.  But what kinds?

Is this like the rsh and rlogin vulnerability?  It's well documented
that you should not install rsh and rlogin and then set the first line
of /etc/hosts.equive or ~root/.rhosts to an asterisk in the first and
only line.  There are numerous exploits that show that require these
types of "special configurations" which requires that users completely
ignore documentation telling you not to do it.  Administrators know
better.  Unsophisticated users might be fooled into running a shell
script, but to get root access, they would have to configure Linux.

> </quote>

Rex Ballard <rex.ballard@gmail.com> writes:

> On Sep 18, 8:47 am, "Ezekiel" <M...@Not-there.com> wrote:
>> <quote>
>> Hole in Linux kernel provides root rights
>> 17 September 2010
>
>> A vulnerability in the 32-bit compatibility mode of the current Linux kernel
>> (and previous versions) for 64-bit systems can be exploited to escalate
>> privileges. For instance, attackers can break into a system and exploit a
>> hole in the web server to get complete root (also known as superuser) rights
>> or permissions for a victim's system.
>
> How many hackers have successfully exploited this vulnerability?

I dont suppose people really care.

On 2010-09-19, Hadron <hadronquark@gmail.com> wrote:
>
>
> Rex Ballard <rex.ballard@gmail.com> writes:
>
>> On Sep 18, 8:47 am, "Ezekiel" <M...@Not-there.com> wrote:
>>> <quote>
>>> Hole in Linux kernel provides root rights
>>> 17 September 2010
>>
>>> A vulnerability in the 32-bit compatibility mode of the current Linux kernel
>>> (and previous versions) for 64-bit systems can be exploited to escalate
>>> privileges. For instance, attackers can break into a system and exploit a
>>> hole in the web server to get complete root (also known as superuser) rights
>>> or permissions for a victim's system.
>>
>> How many hackers have successfully exploited this vulnerability?
>
> I dont suppose people really care.

    Obviously YOU care. You like to drone on about how eggregious this is.

-- 

   Nevermind the pirates. Sony needs to worry about it's own back catalog. |||
   	     	 	       	     	      	    	     	  	  / | \

JEDIDIAH <jedi@nomad.mishnet> writes:

> On 2010-09-19, Hadron <hadronquark@gmail.com> wrote:
>>
>>
>> Rex Ballard <rex.ballard@gmail.com> writes:
>>
>>> On Sep 18, 8:47 am, "Ezekiel" <M...@Not-there.com> wrote:
>>>> <quote>
>>>> Hole in Linux kernel provides root rights
>>>> 17 September 2010
>>>
>>>> A vulnerability in the 32-bit compatibility mode of the current Linux kernel
>>>> (and previous versions) for 64-bit systems can be exploited to escalate
>>>> privileges. For instance, attackers can break into a system and exploit a
>>>> hole in the web server to get complete root (also known as superuser) rights
>>>> or permissions for a victim's system.
>>>
>>> How many hackers have successfully exploited this vulnerability?
>>
>> I dont suppose people really care.
>
>     Obviously YOU care. You like to drone on about how eggregious this is.

You are a liar. I dont at all.

I point out that ALL SW has bugs including Linux. And that, of course,
so few desktops are Linux that the nasty hackers dont really target it.

Q: How do YOU know that hackers haven't been quietly reading all
your/others mail for years at google as a result of this?

A lot of Linux users, like that idiot Steve Smith who was boasting about
his uptime of years, are so smug they really think their servers are
secure. TheyÄre not. And these posts are a reminder.

Don't believe me? Subscribe to the Debian Security Bulletin.

On Sun, 19 Sep 2010 21:57:43 +0200, Hadron<hadronquark@gmail.com>
wrote:

>JEDIDIAH <jedi@nomad.mishnet> writes:
>
>> On 2010-09-19, Hadron <hadronquark@gmail.com> wrote:
>>>
>>>
>>> Rex Ballard <rex.ballard@gmail.com> writes:
>>>
>>>> On Sep 18, 8:47�am, "Ezekiel" <M...@Not-there.com> wrote:
>>>>> <quote>
>>>>> Hole in Linux kernel provides root rights
>>>>> 17 September 2010
>>>>
>>>>> A vulnerability in the 32-bit compatibility mode of the current Linux kernel
>>>>> (and previous versions) for 64-bit systems can be exploited to escalate
>>>>> privileges. For instance, attackers can break into a system and exploit a
>>>>> hole in the web server to get complete root (also known as superuser) rights
>>>>> or permissions for a victim's system.
>>>>
>>>> How many hackers have successfully exploited this vulnerability?
>>>
>>> I dont suppose people really care.
>>
>>     Obviously YOU care. You like to drone on about how eggregious this is.
>
>You are a liar. I dont at all.

I don't care either.
If I use the software, I get the patch.

Just like any other piece of software.


>I point out that ALL SW has bugs including Linux. And that, of course,
>so few desktops are Linux that the nasty hackers dont really target it.

True.
The Linux loons don't like it being pointed out either.

Had this been the NT kernel with the same set of criteria, the
Linturds would be twitching and writhing with some sort of weird joy.

>Q: How do YOU know that hackers haven't been quietly reading all
>your/others mail for years at google as a result of this?
>
>A lot of Linux users, like that idiot Steve Smith who was boasting about
>his uptime of years, are so smug they really think their servers are
>secure. They�re not. And these posts are a reminder.
>
>Don't believe me? Subscribe to the Debian Security Bulletin.

Up time like everything is a choice and at the same time a compromise.

Up time is a great thing for places that truly cannot be taken down
conveniently.
However, most places, systems do not fall into that category and for
those people, the majority, bragging about up time signifies their
stupidity at not patching their systems in a timely fashion.

I would take security over up time, or at least a compromise of the
two, any day of the week over pure up time.
-- 
Moshe Goldfarb
Collector of soaps from around the globe.
Linux...Disappointing users for 19 years.
Linux::It's free when your time has no value.
See Liarmutt in action http://www.youtube.com/watch?v=SazBzvQ0ZAM

Ezekiel wrote:
> <quote>
> Hole in Linux kernel provides root rights
> 17 September 2010
> 
> A vulnerability in the 32-bit compatibility mode of the current Linux
> kernel (and previous versions) for 64-bit systems can be exploited to
> escalate privileges. For instance, attackers can break into a system and
> exploit a hole in the web server to get complete root (also known as
> superuser) rights or permissions for a victim's system.
> 
> The kernel developers have remedied the flaw in the repository, and Linux
> distributors will probably soon publish new kernels to close the hole.
> Until then, switching off 32-bit ELF support solves the problem if you can
> do without this function.
> 
> Hawkes says the vulnerability was discovered and remedied back in 2007,
> but at some point in 2008 kernel developers apparently removed the patch,
> reintroducing the vulnerability. The older exploit apparently only needed
> slight modifications to work with the new hole.
> </quote>

"Hawkes says the vulnerability was discovered  and remedied back in 2007, 
but at some point in 2008 kernel developers apparently removed the patch, 
reintroducing the vulnerability. The older exploit apparently only needed 
slight modifications to work with the new hole."
<http://www.h-online.com/open/news/item/Hole-in-Linux-kernel-provides-root-
rights-Update-1081317.html>

It seem this bug had already been reported and fixed in 2007, but the 
corrective patch was removed in 2008, for whatever reason. Avoiding bugs in 
such a large body of code is difficult, but this this kind of blunder should 
be avoided. Maybe creating a test library of exploits that are run against 
release candidate kernels to verify that vulnerabilities don't resurface.

The fixes are already available for most main distros, so update your 
systems and reboot to the new kernel.

On a curiosity note, before booting the new kernel, I compiled and used the 
exploit code but it did not work. Maybe some MAC rules are blocking it.

$ gcc -Wall -Wextra robert_you_suck.c -o robert_you_suck
robert_you_suck.c: In function ‘kernelmodecode’:
robert_you_suck.c:33: warning: unused parameter ‘file’
robert_you_suck.c:33: warning: unused parameter ‘vma’
$ ./robert_you_suck
resolved symbol commit_creds to 0xffffffff8107c2b0
resolved symbol prepare_kernel_cred to 0xffffffff8107c430
mapping at 3f80000000
UID 1000, EUID:1000 GID:1000, EGID:1000
sh-4.0$ cd /root/
sh: cd: /root/: Permissão negada
sh-4.0$ exit

Regards.

Lusotec posted this message in ROT13 encoding:

> <http://www.h-online.com/open/news/item/Hole-in-Linux-kernel-provides-root-rights-Update-1081317.html>
>
> It seem this bug had already been reported and fixed in 2007, but the 
> corrective patch was removed in 2008, for whatever reason. Avoiding bugs in 
> such a large body of code is difficult, but this this kind of blunder should 
> be avoided. Maybe creating a test library of exploits that are run against 
> release candidate kernels to verify that vulnerabilities don't resurface.

Or putting a comment in the code :-)

-- 
I'm not sure how much writing happened. You know, let's play E minor and A for
an hour or two. Oh, that sounds all right, that'll take up five minutes.
		-- Roger Waters, on the composition of "Breathe"

On 9/22/2010 6:15 AM, Lusotec wrote:

> "Hawkes says the vulnerability was discovered  and remedied back in 2007,
> but at some point in 2008 kernel developers apparently removed the patch,
> reintroducing the vulnerability. The older exploit apparently only needed
> slight modifications to work with the new hole."
> <http://www.h-online.com/open/news/item/Hole-in-Linux-kernel-provides-root-
> rights-Update-1081317.html>


"the problem occurs because the 32-bit call emulation layer does not 
check whether the call is truly in the Syscall table."

There's that "insecure by design" you insisted over and over and over 
was not present in Lunix.

DFS wrote:
> Lusotec wrote:
>> "Hawkes says the vulnerability was discovered  and remedied back in 2007,
>> but at some point in 2008 kernel developers apparently removed the patch,
>> reintroducing the vulnerability. The older exploit apparently only needed
>> slight modifications to work with the new hole."
>> <http://www.h-online.com/open/news/item/Hole-in-Linux-kernel-provides-
>> root-rights-Update-1081317.html>
> 
> "the problem occurs because the 32-bit call emulation layer does not
> check whether the call is truly in the Syscall table."
> 
> There's that "insecure by design" you insisted over and over and over
> was not present in Lunix.

First, this is a insecure by *implementation*, not by design.

Second, I never insisted (or said) there are no insecure by design aspects 
in Linux (I know a few, by the way). I just asked you to support your 
statement that "Linux is insecure by design". You never did and apparently 
you don't know the meaning of "insecure by design". It is no surprise then, 
that you can't point to a single case of insecure by *design* for Linux.

Regards.

On 9/22/2010 6:53 PM, Lusotec wrote:
> DFS wrote:
>> Lusotec wrote:
>>> "Hawkes says the vulnerability was discovered  and remedied back in 2007,
>>> but at some point in 2008 kernel developers apparently removed the patch,
>>> reintroducing the vulnerability. The older exploit apparently only needed
>>> slight modifications to work with the new hole."
>>> <http://www.h-online.com/open/news/item/Hole-in-Linux-kernel-provides-
>>> root-rights-Update-1081317.html>
>>
>> "the problem occurs because the 32-bit call emulation layer does not
>> check whether the call is truly in the Syscall table."
>>
>> There's that "insecure by design" you insisted over and over and over
>> was not present in Lunix.
>
> First, this is a insecure by *implementation*, not by design.
>
> Second, I never insisted (or said) there are no insecure by design aspects
> in Linux (I know a few, by the way). I just asked you to support your
> statement that "Linux is insecure by design". You never did and apparently
> you don't know the meaning of "insecure by design".

For instance, the options given during install of Pardus to give users 
root and no required password are insecure by design features.

http://en.pardus-wiki.org/Pardus:Installation2009#Create_User.28s.29





> It is no surprise then,
> that you can't point to a single case of insecure by *design* for Linux.


I just did, and in the past.  You can deny it until you die, but Linux 
is still insecure by design.

DFS wrote:
> Lusotec wrote:
>> DFS wrote:
>>> Lusotec wrote:
>>>> "Hawkes says the vulnerability was discovered  and remedied back in
>>>> 2007, but at some point in 2008 kernel developers apparently removed
>>>> the patch, reintroducing the vulnerability. The older exploit
>>>> apparently only needed slight modifications to work with the new hole."
>>>> <http://www.h-online.com/open/news/item/Hole-in-Linux-kernel-provides-
>>>> root-rights-Update-1081317.html>
>>>
>>> "the problem occurs because the 32-bit call emulation layer does not
>>> check whether the call is truly in the Syscall table."
>>>
>>> There's that "insecure by design" you insisted over and over and over
>>> was not present in Lunix.
>>
>> First, this is a insecure by *implementation*, not by design.
>>
>> Second, I never insisted (or said) there are no insecure by design
>> aspects in Linux (I know a few, by the way). I just asked you to support
>> your statement that "Linux is insecure by design". You never did and
>> apparently you don't know the meaning of "insecure by design".
> 
> For instance, the options given during install of Pardus to give users
> root and no required password are insecure by design features.
> 
> http://en.pardus-wiki.org/Pardus:Installation2009#Create_User.28s.29

Yes, that is a insecure by design example but for Pardus distribution, not 
for GNU/Linux.

>> It is no surprise then,
>> that you can't point to a single case of insecure by *design* for Linux.
> 
> I just did, and in the past.

No you didn't, and no you haven't.

> You can deny it until you die, but Linux is still insecure by design.

I never denied it, in fact, I agree, GNU/Linux has several insecure by 
design aspects, but you still have not shown one single example to support 
that claim.

Regards.

Lusotec <nomail@nomail.not> writes:

> DFS wrote:
>> Lusotec wrote:
>>> DFS wrote:
>>>> Lusotec wrote:
>>>>> "Hawkes says the vulnerability was discovered  and remedied back in
>>>>> 2007, but at some point in 2008 kernel developers apparently removed
>>>>> the patch, reintroducing the vulnerability. The older exploit
>>>>> apparently only needed slight modifications to work with the new hole."
>>>>> <http://www.h-online.com/open/news/item/Hole-in-Linux-kernel-provides-
>>>>> root-rights-Update-1081317.html>
>>>>
>>>> "the problem occurs because the 32-bit call emulation layer does not
>>>> check whether the call is truly in the Syscall table."
>>>>
>>>> There's that "insecure by design" you insisted over and over and over
>>>> was not present in Lunix.
>>>
>>> First, this is a insecure by *implementation*, not by design.
>>>
>>> Second, I never insisted (or said) there are no insecure by design
>>> aspects in Linux (I know a few, by the way). I just asked you to support
>>> your statement that "Linux is insecure by design". You never did and
>>> apparently you don't know the meaning of "insecure by design".
>> 
>> For instance, the options given during install of Pardus to give users
>> root and no required password are insecure by design features.
>> 
>> http://en.pardus-wiki.org/Pardus:Installation2009#Create_User.28s.29
>
> Yes, that is a insecure by design example but for Pardus distribution, not 
> for GNU/Linux.

LOL. Linux == kernel again ...

What about being about being able to turn on sudo timeouts?

Easy to forget and wander out of the room effectively leaving root
access.

>
>>> It is no surprise then,
>>> that you can't point to a single case of insecure by *design* for Linux.
>> 
>> I just did, and in the past.
>
> No you didn't, and no you haven't.
>
>> You can deny it until you die, but Linux is still insecure by design.
>
> I never denied it, in fact, I agree, GNU/Linux has several insecure by 
> design aspects, but you still have not shown one single example to support 
> that claim.
>
> Regards.

Hadron wrote:
> Lusotec writes:
>> DFS wrote:
>>> For instance, the options given during install of Pardus to give users
>>> root and no required password are insecure by design features.
>>> 
>>> http://en.pardus-wiki.org/Pardus:Installation2009#Create_User.28s.29
>>
>> Yes, that is a insecure by design example but for Pardus distribution,
>> not for GNU/Linux.
> 
> LOL. Linux == kernel again ...

LOL. I explicitly wrote GNU/Linux...

But since you have decided to participate maybe you could tell us if you 
think a insecure design aspect on a install tool used by Pardus is a 
insecure design aspect of GNU/Linux?

> What about being about being able to turn on sudo timeouts?
>
> Easy to forget and wander out of the room effectively leaving root
> access.

Sudo's default for the password timeout is 5 minutes (I think). What is the 
optimum timeout point is debatable. Too long and you run the risk of leaving 
the system's access open at the local terminal. Too short and it can become 
a annoyance and make the user choose other, possibly less secure methods. I 
personally feel that 5 minutes is a good enough choice for my usage 
patterns.

Do you think there should *not* be a timeout? That sudo should always ask 
for a password? That sudo should ask only once per session for the password? 
Do you think the whole timeout aspect is a insecure design decision? Or just 
the particular default value? Please clarify.

Regards.

Lusotec <nomail@nomail.not> writes:

> Hadron wrote:
>> Lusotec writes:
>>> DFS wrote:
>>>> For instance, the options given during install of Pardus to give users
>>>> root and no required password are insecure by design features.
>>>> 
>>>> http://en.pardus-wiki.org/Pardus:Installation2009#Create_User.28s.29
>>>
>>> Yes, that is a insecure by design example but for Pardus distribution,
>>> not for GNU/Linux.
>> 
>> LOL. Linux == kernel again ...
>
> LOL. I explicitly wrote GNU/Linux...

Immaterial. Are you on the sherry again?

>
> But since you have decided to participate maybe you could tell us if you 
> think a insecure design aspect on a install tool used by Pardus is a 
> insecure design aspect of GNU/Linux?

Sure. Because "advocates" understand that any program that abuses APIs
etc can only do so because of fundamental weaknesses in the underlying
OS.

See?

>
>> What about being about being able to turn on sudo timeouts?
>>
>> Easy to forget and wander out of the room effectively leaving root
>> access.
>
> Sudo's default for the password timeout is 5 minutes (I think). What is the 
> optimum timeout point is debatable. Too long and you run the risk of
> leaving 

How long does it take to go outside for a quick piddle?

My point is valid. I'm sure you'll argue to the death.

You need to realise when someone's playing devil's advocate.

Hadron wrote:
> Lusotec writes:
>> Hadron wrote:
>>> Lusotec writes:
>>>> DFS wrote:
>>>>> For instance, the options given during install of Pardus to give users
>>>>> root and no required password are insecure by design features.
>>>>> 
>>>>> http://en.pardus-wiki.org/Pardus:Installation2009#Create_User.28s.29
>>>>
>>>> Yes, that is a insecure by design example but for Pardus distribution,
>>>> not for GNU/Linux.
>>> 
>>> LOL. Linux == kernel again ...
>>
>> LOL. I explicitly wrote GNU/Linux...
> 
> Immaterial. Are you on the sherry again?

Immaterial?!

>> But since you have decided to participate maybe you could tell us if you
>> think a insecure design aspect on a install tool used by Pardus is a
>> insecure design aspect of GNU/Linux?
> 
> Sure. Because "advocates" understand that any program that abuses APIs
> etc can only do so because of fundamental weaknesses in the underlying
> OS.

The Pardus installer allowing for empty password has nothing to do with 
weaknesses in the underlying OS (or APIs). Both empty password and auto 
login, by the way, have valid uses and the underlying OS should not prevent 
those two use cases.

For example:
- All my personal desktop and laptop systems are set to auto login to my 
account. The file systems are encrypted. I have to plug a USB key and enter 
a password to unlock the file systems and start the OS. Requiring a user 
account password would be redundant;
- Public system where the guest account has an empty password and auto 
logins to it are also useful;
- Non empty passwords in LiveCD OSs are most likely unnecessary and 
unwelcome;
- There are systems where explicit users and authentication make no sense 
(e.g. some embedded systems).

> See?

Yes, perfectly.

>>> What about being about being able to turn on sudo timeouts?
>>>
>>> Easy to forget and wander out of the room effectively leaving root
>>> access.
>>
>> Sudo's default for the password timeout is 5 minutes (I think). What is
>> the optimum timeout point is debatable. Too long and you run the risk of
>> leaving
> 
> How long does it take to go outside for a quick piddle?
>
> My point is valid. I'm sure you'll argue to the death.
> 
> You need to realise when someone's playing devil's advocate.

Regards.

Lusotec posted this message in ROT13 encoding:

> Hadron wrote:
>
>> What about being about being able to turn on sudo timeouts?
>>
>> Easy to forget and wander out of the room effectively leaving root
>> access.
>
> Sudo's default for the password timeout is 5 minutes (I think). What is the 
> optimum timeout point is debatable. Too long and you run the risk of leaving 
> the system's access open at the local terminal. Too short and it can become 
> a annoyance and make the user choose other, possibly less secure methods. I 
> personally feel that 5 minutes is a good enough choice for my usage 
> patterns.
>
> Do you think there should *not* be a timeout? That sudo should always ask 
> for a password? That sudo should ask only once per session for the password? 
> Do you think the whole timeout aspect is a insecure design decision? Or just 
> the particular default value? Please clarify.

Personally, I would prefer to log in as root and then exit root as soon as I
am done with the series of commands.

That '#' prompt is a nice visual cue.  :-)

-- 
"I got a question for ya.  Ya got a minute?"
		-- two programmers passing in the hall

On 2010-09-23, Chris Ahlstrom <ahlstrom@xzoozy.com> wrote:
> Lusotec posted this message in ROT13 encoding:
>
>> Hadron wrote:
>>
>>> What about being about being able to turn on sudo timeouts?
>>>
>>> Easy to forget and wander out of the room effectively leaving root
>>> access.
>>
>> Sudo's default for the password timeout is 5 minutes (I think). What is the 
>> optimum timeout point is debatable. Too long and you run the risk of leaving 
>> the system's access open at the local terminal. Too short and it can become 
>> a annoyance and make the user choose other, possibly less secure methods. I 
>> personally feel that 5 minutes is a good enough choice for my usage 
>> patterns.
>>
>> Do you think there should *not* be a timeout? That sudo should always ask 
>> for a password? That sudo should ask only once per session for the password? 
>> Do you think the whole timeout aspect is a insecure design decision? Or just 
>> the particular default value? Please clarify.
>
> Personally, I would prefer to log in as root and then exit root as soon as I
> am done with the series of commands.
>
> That '#' prompt is a nice visual cue.  :-)

My terminal uses different colours to give even more of a root login visual cue:

From /etc/bash/bashrc

[...]

if [[ ${EUID} == 0 ]] ; then
	PS1='\[\033[01;31m\]\h\[\033[01;34m\] \W \$\[\033[00m\] '
else
	PS1='\[\033[01;32m\]\u@\h\[\033[01;34m\] \w \$\[\033[00m\] '
fi

[...]

I don't use sudo on my Gentoo boxes but since I installed Ubuntu 10.4 on
my Eeepc701 I've been using sudo a lot. I don't mind it.

-- 
Regards,

Gregory.
Gentoo Linux - Penguin Power

Chris Ahlstrom <ahlstrom@xzoozy.com> writes:

> Lusotec posted this message in ROT13 encoding:
>
>> Hadron wrote:
>>
>>> What about being about being able to turn on sudo timeouts?
>>>
>>> Easy to forget and wander out of the room effectively leaving root
>>> access.
>>
>> Sudo's default for the password timeout is 5 minutes (I think). What is the 
>> optimum timeout point is debatable. Too long and you run the risk of leaving 
>> the system's access open at the local terminal. Too short and it can become 
>> a annoyance and make the user choose other, possibly less secure methods. I 
>> personally feel that 5 minutes is a good enough choice for my usage 
>> patterns.
>>
>> Do you think there should *not* be a timeout? That sudo should always ask 
>> for a password? That sudo should ask only once per session for the password? 
>> Do you think the whole timeout aspect is a insecure design decision? Or just 
>> the particular default value? Please clarify.
>
> Personally, I would prefer to log in as root and then exit root as soon as I
> am done with the series of commands.
>
> That '#' prompt is a nice visual cue.  :-)

So is the "sudo" prefix...

You clearly dont understand or, alternatively, accept the reasons for
sudo if you prefer using su.

There is almost never a reason to log into a shell as root these
days. Not to say its not necessary, but rarely.

Gregory Shearman <ZekeGregory@netscape.net> writes:

> On 2010-09-23, Chris Ahlstrom <ahlstrom@xzoozy.com> wrote:
>> Lusotec posted this message in ROT13 encoding:
>>
>>> Hadron wrote:
>>>
>>>> What about being about being able to turn on sudo timeouts?
>>>>
>>>> Easy to forget and wander out of the room effectively leaving root
>>>> access.
>>>
>>> Sudo's default for the password timeout is 5 minutes (I think). What is the 
>>> optimum timeout point is debatable. Too long and you run the risk of leaving 
>>> the system's access open at the local terminal. Too short and it can become 
>>> a annoyance and make the user choose other, possibly less secure methods. I 
>>> personally feel that 5 minutes is a good enough choice for my usage 
>>> patterns.
>>>
>>> Do you think there should *not* be a timeout? That sudo should always ask 
>>> for a password? That sudo should ask only once per session for the password? 
>>> Do you think the whole timeout aspect is a insecure design decision? Or just 
>>> the particular default value? Please clarify.
>>
>> Personally, I would prefer to log in as root and then exit root as soon as I
>> am done with the series of commands.
>>
>> That '#' prompt is a nice visual cue.  :-)
>
> My terminal uses different colours to give even more of a root login visual cue:
>
> From /etc/bash/bashrc
>
> [...]
>
> if [[ ${EUID} == 0 ]] ; then
> 	PS1='\[\033[01;31m\]\h\[\033[01;34m\] \W \$\[\033[00m\] '
> else
> 	PS1='\[\033[01;32m\]\u@\h\[\033[01;34m\] \w \$\[\033[00m\] '
> fi
>
> [...]
>
> I don't use sudo on my Gentoo boxes but since I installed Ubuntu 10.4 on
> my Eeepc701 I've been using sudo a lot. I don't mind it.

Even cooler is incorporating the current git branch into the prompt. e.g

export
PS1='[\!]\[\033[00;32m\]\u\[\033[01m\]@\[\033[00;36m\]\h\[\033[01m\]:\[\033[00;35m\]\w\[\033[00m\]\[\033[01;33m\]`git
branch 2>/dev/null|cut -f2 -d\* -s`\[\033[00m\]\$ '

Gregory Shearman posted this message in ROT13 encoding:

> On 2010-09-23, Chris Ahlstrom <ahlstrom@xzoozy.com> wrote:
>>
>> Personally, I would prefer to log in as root and then exit root as soon as I
>> am done with the series of commands.
>>
>> That '#' prompt is a nice visual cue.  :-)
>
> My terminal uses different colours to give even more of a root login visual cue:
>
> From /etc/bash/bashrc
>
> [...]
>
> if [[ ${EUID} == 0 ]] ; then
> 	PS1='\[\033[01;31m\]\h\[\033[01;34m\] \W \$\[\033[00m\] '
> else
> 	PS1='\[\033[01;32m\]\u@\h\[\033[01;34m\] \w \$\[\033[00m\] '
> fi
>
> [...]

Ahh, I remember that from my time using Gentoo.

> I don't use sudo on my Gentoo boxes but since I installed Ubuntu 10.4 on
> my Eeepc701 I've been using sudo a lot. I don't mind it.

Choice is good!

-- 
A man who fishes for marlin in ponds
will put his money in Etruscan bonds.

Gregory Shearman wrote:

>My terminal uses different colours to give even more of a root login visual cue:

When I do a Windwoes box for someone (malware re-install), I setup the
admin account to be inhospitable, with a plain background, removal
shortcuts to apps, etc, to deter them from using it.

Doesn't prevent abuse, of course, but I give them a quick lecture and
hope that I'm not asked to do it again...

I'll mention Linux, but, sheesh, people can be so scared of trying
something different.  They get so set in their ways.

"chrisv" <chrisv@nospam.invalid> wrote in message 
news:8sjm96pubevcu4lr9dj7k2jnvonqq26gb0@4ax.com...

shut the fsck up you lying piece of shit.

On Thu, 23 Sep 2010 08:06:19 -0500, chrisv <chrisv@nospam.invalid> wrote:
>Gregory Shearman wrote:

>>My terminal uses different colours to give even more of a root login visual cue:

>When I do a Windwoes box for someone (malware re-install), I setup the
>admin account to be inhospitable, with a plain background, removal
>shortcuts to apps, etc, to deter them from using it.

>Doesn't prevent abuse, of course, but I give them a quick lecture and
>hope that I'm not asked to do it again...

>I'll mention Linux, but, sheesh, people can be so scared of trying
>something different.  They get so set in their ways.

The problem with windows is that if you're not an admin, many apps won't
work.  run-as usually won't help either as they'll access the wrong
directory for user files.  

Who the hell wants to play the game:  log out;  log in as admin;
change user to admin;  log out;  log in as user and do whatever didn't
work before;  log out;  log in as admin;  change user back;  log out;
log in as user....