Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.misc > #1554 > unrolled thread

Good Linux to start with

Back to article view | Back to comp.os.linux.misc

Contents

  Good Linux to start with Halberstam Reader <joe.snod@yahoo.com> - 2011-07-03 18:40 -0700
    Re: Good Linux to start with John Hasler <jhasler@newsguy.com> - 2011-07-03 20:53 -0500
    Re: Good Linux to start with bosco <boscopelone@yahoo.com> - 2011-07-03 21:16 -0600
      Re: Good Linux to start with bruce.sinclair@NOSPAMORELSEagresearch.NOTco.NOTnz (Bruce Sinclair) - 2011-07-04 04:07 +0000
    Re: Good Linux to start with Dan C <youmustbejoking@lan.invalid> - 2011-07-04 03:28 +0000
      Re: Good Linux to start with Michael Black <et472@ncf.ca> - 2011-07-04 12:04 -0400
        Re: Good Linux to start with Aragorn <stryder@telenet.be.invalid> - 2011-07-04 23:07 +0200
    Re: Good Linux to start with David Brown <david@westcontrol.removethisbit.com> - 2011-07-04 10:15 +0200
    Re: Good Linux to start with Bob Henson <rh547477@gmail.com> - 2011-07-04 10:00 +0100
    Re: Good Linux to start with Torsten Mueller <dev-null@shared-files.de> - 2011-07-04 11:10 +0200
      Re: Good Linux to start with Balwinder S Dheeman <bsd.SANSPAM@anu.homelinux.net> - 2011-07-04 16:11 +0530
    Re: Good Linux to start with Richard Kimber <richardkimber@btinternet.com> - 2011-07-04 06:59 -0500
      Re: Good Linux to start with The Natural Philosopher <tnp@invalid.invalid> - 2011-07-04 13:35 +0100
        Re: Good Linux to start with David Brown <david@westcontrol.removethisbit.com> - 2011-07-04 15:25 +0200
      Re: Good Linux to start with Mark <i@dontgetlotsofspamanymore.invalid> - 2011-07-05 11:41 +0100
    Re: Good Linux to start with jmclnx@SPAMisBADgmail.com (Jack McCue) - 2011-07-04 12:50 +0000
    Re: Good Linux to start with Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> - 2011-07-04 07:47 -0700
    Re: Good Linux to start with ray <ray@zianet.com> - 2011-07-04 14:50 +0000
    Re: Good Linux to start with Stefan Patric <not@this.address.com> - 2011-07-04 17:23 +0000
      Re: Good Linux to start with Steve Hayes <hayesstw@telkomsa.net> - 2011-07-05 07:39 +0200
        Re: Good Linux to start with JohnT <john@example.com> - 2011-07-05 07:52 +0000
          Re: Good Linux to start with Robert Riches <spamtrap42@jacob21819.net> - 2011-07-05 15:51 +0000
          Re: Good Linux to start with Aragorn <stryder@telenet.be.invalid> - 2011-07-06 03:46 +0200
            Re: Good Linux to start with "Peter J. Holzer" <hjp-usenet2@hjp.at> - 2011-07-07 22:35 +0200
              Re: Good Linux to start with Aragorn <stryder@telenet.be.invalid> - 2011-07-07 23:06 +0200
                Re: Good Linux to start with "Peter J. Holzer" <hjp-usenet2@hjp.at> - 2011-07-08 13:44 +0200
                  Re: Good Linux to start with Hans Georg Schaathun <hg@schaathun.net> - 2011-07-13 08:58 +0100
                    Re: Good Linux to start with Mark <i@dontgetlotsofspamanymore.invalid> - 2011-07-13 09:41 +0100
                    Re: Good Linux to start with Richard Kettlewell <rjk@greenend.org.uk> - 2011-07-13 10:07 +0100
                      Re: Good Linux to start with Hans Georg Schaathun <hg@schaathun.net> - 2011-07-13 12:46 +0100
                        Re: Good Linux to start with Richard Kettlewell <rjk@greenend.org.uk> - 2011-07-13 13:47 +0100
                          Re: Good Linux to start with Hans Georg Schaathun <hg@schaathun.net> - 2011-07-13 14:20 +0100
                            Re: Good Linux to start with Richard Kettlewell <rjk@greenend.org.uk> - 2011-07-13 15:26 +0100
                    Re: Good Linux to start with John Hasler <jhasler@newsguy.com> - 2011-07-13 07:37 -0500
                      Re: Good Linux to start with Hans Georg Schaathun <hg@schaathun.net> - 2011-07-13 14:16 +0100
                        Re: Good Linux to start with The Natural Philosopher <tnp@invalid.invalid> - 2011-07-13 14:35 +0100
                          Re: Good Linux to start with Hans Georg Schaathun <hg@schaathun.net> - 2011-07-13 15:13 +0100
                            Re: Good Linux to start with Richard Kettlewell <rjk@greenend.org.uk> - 2011-07-13 16:36 +0100
              Re: Good Linux to start with Mark <i@dontgetlotsofspamanymore.invalid> - 2011-07-08 08:53 +0100
                Re: Good Linux to start with "Peter J. Holzer" <hjp-usenet2@hjp.at> - 2011-07-08 14:09 +0200
    Re: Good Linux to start with Anton Meyninger <anton.meyninger@gmail.com> - 2011-07-05 13:07 +0200
      Re: Good Linux to start with Aragorn <stryder@telenet.be.invalid> - 2011-07-06 03:52 +0200
        Re: Good Linux to start with The Natural Philosopher <tnp@invalid.invalid> - 2011-07-06 12:16 +0100
          Re: Good Linux to start with Aragorn <stryder@telenet.be.invalid> - 2011-07-06 19:10 +0200
            Re: Good Linux to start with The Natural Philosopher <tnp@invalid.invalid> - 2011-07-06 18:30 +0100
              Re: Good Linux to start with Aragorn <stryder@telenet.be.invalid> - 2011-07-07 01:57 +0200
                Re: Good Linux to start with Robert Riches <spamtrap42@jacob21819.net> - 2011-07-07 03:26 +0000
                  Re: Good Linux to start with The Natural Philosopher <tnp@invalid.invalid> - 2011-07-07 05:48 +0100
                  Re: Good Linux to start with Balwinder S Dheeman <bsd.SANSPAM@anu.homelinux.net> - 2011-07-07 11:15 +0530
                    Re: Good Linux to start with The Natural Philosopher <tnp@invalid.invalid> - 2011-07-07 07:14 +0100
                Re: Good Linux to start with The Natural Philosopher <tnp@invalid.invalid> - 2011-07-07 05:45 +0100
                Re: Good Linux to start with Richard Kettlewell <rjk@greenend.org.uk> - 2011-07-07 09:53 +0100
                  Re: Good Linux to start with Mark <i@dontgetlotsofspamanymore.invalid> - 2011-07-07 10:41 +0100
                    Re: Good Linux to start with Richard Kettlewell <rjk@greenend.org.uk> - 2011-07-07 11:32 +0100
                      Re: Good Linux to start with The Natural Philosopher <tnp@invalid.invalid> - 2011-07-07 13:49 +0100
                        Re: Good Linux to start with Mark <i@dontgetlotsofspamanymore.invalid> - 2011-07-07 15:01 +0100
                          Re: Good Linux to start with The Natural Philosopher <tnp@invalid.invalid> - 2011-07-07 15:16 +0100
                            Re: Good Linux to start with "Peter J. Holzer" <hjp-usenet2@hjp.at> - 2011-07-07 23:04 +0200
                              Re: Good Linux to start with Mark <i@dontgetlotsofspamanymore.invalid> - 2011-07-08 08:58 +0100
                                Re: Good Linux to start with "Peter J. Holzer" <hjp-usenet2@hjp.at> - 2011-07-08 14:19 +0200
                              Re: Good Linux to start with The Natural Philosopher <tnp@invalid.invalid> - 2011-07-08 13:44 +0100
                                Re: Good Linux to start with Mark <i@dontgetlotsofspamanymore.invalid> - 2011-07-11 09:39 +0100
                        Re: Good Linux to start with blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-07-10 19:02 +0000
                      Re: Good Linux to start with blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-07-10 19:01 +0000
              Re: Good Linux to start with Robert Riches <spamtrap42@jacob21819.net> - 2011-07-07 03:16 +0000
                Re: Good Linux to start with The Natural Philosopher <tnp@invalid.invalid> - 2011-07-07 05:47 +0100
                  Re: Good Linux to start with Robert Riches <spamtrap42@jacob21819.net> - 2011-07-07 05:00 +0000
            Re: Good Linux to start with "Peter J. Holzer" <hjp-usenet2@hjp.at> - 2011-07-07 22:42 +0200
              Re: Good Linux to start with Aragorn <stryder@telenet.be.invalid> - 2011-07-07 23:41 +0200
                Re: Good Linux to start with "Peter J. Holzer" <hjp-usenet2@hjp.at> - 2011-07-08 14:07 +0200
                  Re: Good Linux to start with Aragorn <stryder@telenet.be.invalid> - 2011-07-09 02:05 +0200
                    Re: Good Linux to start with "Peter J. Holzer" <hjp-usenet2@hjp.at> - 2011-07-09 21:10 +0200
                      Re: Good Linux to start with Aragorn <stryder@telenet.be.invalid> - 2011-07-10 02:16 +0200
                        Re: Good Linux to start with Richard Kettlewell <rjk@greenend.org.uk> - 2011-07-10 10:42 +0100
                          Re: Good Linux to start with Aragorn <stryder@telenet.be.invalid> - 2011-07-11 05:03 +0200
                            Re: Good Linux to start with The Natural Philosopher <tnp@invalid.invalid> - 2011-07-11 08:23 +0100
                              Re: Good Linux to start with Mark <i@dontgetlotsofspamanymore.invalid> - 2011-07-11 09:52 +0100
                            Re: Good Linux to start with Richard Kettlewell <rjk@greenend.org.uk> - 2011-07-11 11:16 +0100
                      Re: Good Linux to start with Robert Riches <spamtrap42@jacob21819.net> - 2011-07-10 03:49 +0000
                        Re: Good Linux to start with "Peter J. Holzer" <hjp-usenet2@hjp.at> - 2011-07-11 13:56 +0200
                          Re: Good Linux to start with blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-07-11 22:31 +0000
                            Re: Good Linux to start with "Peter J. Holzer" <hjp-usenet2@hjp.at> - 2011-07-12 15:30 +0200
                              Re: Good Linux to start with blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-07-12 22:28 +0000
    Re: Good Linux to start with Feranija <feranija@net...> - 2011-07-06 11:37 -0700
    Re: Good Linux to start with TJ <TJ@noneofyour.business> - 2011-07-18 09:35 -0400

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#1582

On Tue, 05 Jul 2011 07:39:41 +0200, Steve Hayes wrote:

> I liked the Ubuntu distro because it had a whole lot of other software
> bundled with it, though I dislike the "sudo" thing, which misses one of
> the big attractions of Linux to me - being able to log in as Root to
> tweak the system, and then log out and log in as myself to use it
> without risk of inadvertently damaging it.

All distros have sudo.
The difference with Ubuntu is that - by default - root has login disabled 
as a safety feature. You just need to use sudo to give root a password 
and you can login as root. Its normally the first thing I do after an 
install.

JohnT

[toc] | [prev] | [next] | [standalone]

#1597

On 2011-07-05, JohnT <john@example.com> wrote:
> On Tue, 05 Jul 2011 07:39:41 +0200, Steve Hayes wrote:
>
>> I liked the Ubuntu distro because it had a whole lot of other software
>> bundled with it, though I dislike the "sudo" thing, which misses one of
>> the big attractions of Linux to me - being able to log in as Root to
>> tweak the system, and then log out and log in as myself to use it
>> without risk of inadvertently damaging it.
>
> All distros have sudo.
> The difference with Ubuntu is that - by default - root has login disabled 
> as a safety feature. You just need to use sudo to give root a password 
> and you can login as root. Its normally the first thing I do after an 
> install.
>
> JohnT

That should work.  Alternatively, you can get a root shell by
doing this:

        sudo su -

-- 
Robert Riches
spamtrap42@jacob21819.net
(Yes, that is one of my email addresses.)

[toc] | [prev] | [next] | [standalone]

#1614

On Tuesday 05 July 2011 09:52 in comp.os.linux.misc, JohnT enlightened 
humanity with the following words...:

> On Tue, 05 Jul 2011 07:39:41 +0200, Steve Hayes wrote:
> 
>> I liked the Ubuntu distro because it had a whole lot of other
>> software bundled with it, though I dislike the "sudo" thing, which
>> misses one of the big attractions of Linux to me - being able to log
>> in as Root to tweak the system, and then log out and log in as myself
>> to use it without risk of inadvertently damaging it.

On UNIX, one does not have to log out in orde to log in as another user.  
It's a multiuser system, which can be used perfectly well by multiple 
users logged in at the same time.

It is however wise to disable root logins - albeit not the way Ubuntu 
does it; see farther down - and to add yourself to the wheel group, and 
use "/bin/su" for gaining root privileges (or for temporarily working as 
another unprivileged user whose password you happen to know).

"/bin/su" is not the same thing as "/usr/bin/sudo".  Read the man pages 
on both to know the difference.  The former is far more secure - again, 
see farther down.

> All distros have sudo. The difference with Ubuntu is that - by default
> - root has login disabled as a safety feature. You just need to use
> sudo to give root a password and you can login as root. Its normally
> the first thing I do after an install.

Yes, a security feature that actually is a security hazard, because with 
the default set-up of "/usr/bin/sudo" - and this /is/ how it is done in 
Ubuntu - it requires the user's _own_ password, not the root password.  
In fact, that's how the root account is disabled in Ubuntu, i.e. it 
doesn't have a password set, which not only means that the root account 
cannot be logged into, but also that one cannot use "/bin/su" to become 
root.

By consequence, an unprivileged user who is listed in "/etc/sudoers" and 
whose account gets compromised - e.g. by an easy-to-guess password - can 
easily be exploited to gain root privileges.

On my systems, I disable root logins the oldfashioned way, i.e. by 
making sure that the "/etc/securetty" is empty (or all entries are 
commented out) and by disallowing root logins over ssh.  I then make 
sure that only the users in the wheel group - and this is my account 
only - can use "/bin/su" to become root, and "/bin/su" _does_ require 
the password of the user account you are trying to log into (which is 
why it cannot be used in Ubuntu).

A properly set-up PAM is crucial.  The problem however here is that PAM 
usually doesn't come properly set up in most distributions, and is by 
consequence way too permissive.  And don't even get me started on the 
way the graphical desktop environments of today bypass security measures 
and offer root user-level privileges to whomever happens to be sitting 
at the local console without requiring _any_ password at all.  I've just 
vented about that with a long rant in another group, so I won't plague 
this one here with the same stuff, but I think you catch my drift.

-- 
Aragorn
(registered GNU/Linux user #223157)

[toc] | [prev] | [next] | [standalone]

#1675

Aragorn <stryder@telenet.be.invalid> schrieb:
> On Tuesday 05 July 2011 09:52 in comp.os.linux.misc, JohnT enlightened 
>> All distros have sudo. The difference with Ubuntu is that - by default
>> - root has login disabled as a safety feature. You just need to use
>> sudo to give root a password and you can login as root. Its normally
>> the first thing I do after an install.
>
> Yes, a security feature that actually is a security hazard, because with 
> the default set-up of "/usr/bin/sudo" - and this /is/ how it is done in 
> Ubuntu - it requires the user's _own_ password, not the root password.  

This is considered a primary security feature of sudo. With su, you need
to give anybody who has to have some elevated privileges the root
password. So all of them have full root privileges and if one of them
loses the privilege, you have to change the password and distribute the
root password to all others. With sudo, you can restrict the privileges
to stuff people actually have to do and if one of them leaves you simply
disable their account or change their sudo settings.

> By consequence, an unprivileged user who is listed in "/etc/sudoers" and 
> whose account gets compromised - e.g. by an easy-to-guess password - can 
> easily be exploited to gain root privileges.

If an account which regulary invokes su is compromised, it is trivial to
compromise the root account, too (unless the user is very very careful -
but then his normal account probably isn't compromised in the first
place). Sudo doesn't make this much easier. Used properly, it makes it
harder (because the compromised account doesn't have unrestricted root
access).

That said, I don't particularly like sudo. IMO it is too complex for
what it does (and security problems do crop up from time to time).


> On my systems, I disable root logins the oldfashioned way, i.e. by 
> making sure that the "/etc/securetty" is empty (or all entries are 
> commented out) and by disallowing root logins over ssh.  I then make 
> sure that only the users in the wheel group - and this is my account 
> only - can use "/bin/su" to become root, and "/bin/su" _does_ require 
> the password of the user account you are trying to log into (which is 
> why it cannot be used in Ubuntu).

If I really had to lock down a system I'd do it the other way around:
Real root privileges can only be aquired by logging in on the console.
For all of the usual root stuff there are suid wrappers.

But normally I'm fine with su.

	hp

[toc] | [prev] | [next] | [standalone]

#1677

On Thursday 07 July 2011 22:35 in comp.os.linux.misc, Peter J. Holzer 
enlightened humanity with the following words...:

> Aragorn <stryder@telenet.be.invalid> schrieb:
>
>> On Tuesday 05 July 2011 09:52 in comp.os.linux.misc, JohnT
>> enlightened [...]
>>
>>> All distros have sudo. The difference with Ubuntu is that - by
>>> default - root has login disabled as a safety feature. You just need
>>> to use sudo to give root a password and you can login as root. Its
>>> normally the first thing I do after an install.
>>
>> Yes, a security feature that actually is a security hazard, because
>> with the default set-up of "/usr/bin/sudo" - and this /is/ how it is
>> done in Ubuntu - it requires the user's _own_ password, not the root
>> password.
> 
> This is considered a primary security feature of sudo. With su, you
> need to give anybody who has to have some elevated privileges the root
> password.

Well, I'm not saying that "/bin/su" should be used as a standalone 
system for elevated privileges.  I agree that "/usr/bin/sudo" is a good 
tool, but not the way it is set up in most distributions, and not as a 
_replacement_ for "/bin/su".

> So all of them have full root privileges and if one of them
> loses the privilege, you have to change the password and distribute
> the root password to all others. With sudo, you can restrict the
> privileges to stuff people actually have to do and if one of them
> leaves you simply disable their account or change their sudo settings.

Of course - role-based access control.  But that is not how most 
distributions set up "/usr/bin/sudo" by default.  And it is certainly 
also not how Ubuntu does it - and Mint, for that matter.  In those two 
distributions, "/usr/bin/sudo" is used as a _substitute_ for "/bin/su", 
and "/bin/su" is disabled because the root account does not have a 
password set.

>> By consequence, an unprivileged user who is listed in "/etc/sudoers"
>> and whose account gets compromised - e.g. by an easy-to-guess
>> password - can easily be exploited to gain root privileges.
> 
> If an account which regulary invokes su is compromised, it is trivial
> to compromise the root account, too (unless the user is very very
> careful - but then his normal account probably isn't compromised in
> the first place).

I don't see how that would be trivial.  First of all you have to 
compromise the account, which means guessing both the login and the 
password.  Then you have to guess the root account's password too.

If you manage to compromise the account of someone who is a /sudoer/ and 
with the way most distributions set up the privileges in "/etc/sudoers", 
then you automatically have root, because all you need to do is use the 
same password as for the account you've already broken into.

> Sudo doesn't make this much easier. Used properly, it makes it harder
> (because the compromised account doesn't have unrestricted root
> access).

Important words: "used properly". ;-)

-- 
Aragorn
(registered GNU/Linux user #223157)

[toc] | [prev] | [next] | [standalone]

#1691

On 2011-07-07 21:06, Aragorn <stryder@telenet.be.invalid> wrote:
> On Thursday 07 July 2011 22:35 in comp.os.linux.misc, Peter J. Holzer 
> enlightened humanity with the following words...:
>
>> Aragorn <stryder@telenet.be.invalid> schrieb:
>>
>>> 
>> So all of them have full root privileges and if one of them
>> loses the privilege, you have to change the password and distribute
>> the root password to all others. With sudo, you can restrict the
>> privileges to stuff people actually have to do and if one of them
>> leaves you simply disable their account or change their sudo settings.
>
> Of course - role-based access control.  But that is not how most 
> distributions set up "/usr/bin/sudo" by default.  And it is certainly 
> also not how Ubuntu does it - and Mint, for that matter.

Well, Ubuntu is intended for single-user systems. Or maybe one
administrator and a handful of other users. So all the roles map onto a
single person and it doesn't make much sense to distinguish them. So
that's the default setup for ubuntu. If your situation is different
(say you've got 3 administrators and 2 of them should only do routine
stuff like updating installed packages and restoring backups) you can
change it. The big advantage of the sudo system is that it keeps people
from working as root all the time. If you get a root shell (whether by
logging in as root or by invoking su) it is easy and convenient to
continue working as root. With sudo you normally only invoke a single
command with root privileges and doing so takes an extra 5 keystrokes.
So it is inconvenient to run something as root and people won't do it.
That may not be a big advantage to long-time sysadmins who have the
necessary discipline, but I think it is an advantage for most of the
people who run Ubuntu at home.


>>> By consequence, an unprivileged user who is listed in "/etc/sudoers"
>>> and whose account gets compromised - e.g. by an easy-to-guess
>>> password - can easily be exploited to gain root privileges.
>> 
>> If an account which regulary invokes su is compromised, it is trivial
>> to compromise the root account, too (unless the user is very very
>> careful - but then his normal account probably isn't compromised in
>> the first place).
>
> I don't see how that would be trivial.  First of all you have to 
> compromise the account,

That part is the same, whether you use sudo or su.

> which means guessing both the login and the 
> password.

Nope. I don't have recent statistics, but I'd guess that most
compromises don't exploit weak passwords, but security holes in
applications. So an attacker who has successfully compromised an account
probably doesn't know the password of the account yet.

> Then you have to guess the root account's password too.

Again, no. You just have to wait until the user invokes su. Intercepting
the password is easy (for example: Put a trojan su in the user's path,
install a keylogger, ...).


> If you manage to compromise the account of someone who is a /sudoer/ and 
> with the way most distributions set up the privileges in "/etc/sudoers", 
> then you automatically have root, because all you need to do is use the 
> same password as for the account you've already broken into.

See above.

	hp

[toc] | [prev] | [next] | [standalone]

#1760

On Fri, 8 Jul 2011 13:44:57 +0200, Peter J. Holzer
  <hjp-usenet2@hjp.at> wrote:
:  That part is the same, whether you use sudo or su.

There is a main difference.  When you run su, you know it, because
it will prompt you for a password /every/ time.  Besides, it will
prompt you for the /root/ password, so there is no risk of confusing
it with some other kind of authorisation.

If you use sudo, it is difficult to prevent a semi-trusted script,
say an install script, from running sudo without your noticing.
If you have used sudo for something else just before, it won't prompt
you for a password at all.  This makes your task harder if you are
quite prepared to take some risks in user space, but try to double-check
everything you run as superuser.

-- 
:-- Hans Georg

[toc] | [prev] | [next] | [standalone]

#1761

On Wed, 13 Jul 2011 08:58:12 +0100, Hans Georg Schaathun
<hg@schaathun.net> wrote:

>If you have used sudo for something else just before, it won't prompt
>you for a password at all.  

You can override this behaviour.
-- 
(\__/)  M.
(='.'=) Due to the amount of spam posted via googlegroups and
(")_(") their inaction to the problem. I am blocking some articles
posted from there.  If you wish your postings to be seen by
everyone you will need use a different method of posting.

[toc] | [prev] | [next] | [standalone]

#1762

Hans Georg Schaathun <hg@schaathun.net> writes:
> Peter J. Holzer <hjp-usenet2@hjp.at> wrote:

>> That part is the same, whether you use sudo or su.
>
> There is a main difference.  When you run su, you know it, because
> it will prompt you for a password /every/ time.  Besides, it will
> prompt you for the /root/ password, so there is no risk of confusing
> it with some other kind of authorisation.
>
> If you use sudo, it is difficult to prevent a semi-trusted script,
> say an install script, from running sudo without your noticing.
> If you have used sudo for something else just before, it won't prompt
> you for a password at all.  This makes your task harder if you are
> quite prepared to take some risks in user space, but try to double-check
> everything you run as superuser.

You need to trust that script, even if you use su instead of sudo; all
you've done is make the path to privilege escalation a bit more
involved.

-- 
http://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#1765

On Wed, 13 Jul 2011 10:07:10 +0100, Richard Kettlewell
  <rjk@greenend.org.uk> wrote:
:  You need to trust that script, even if you use su instead of sudo; all
:  you've done is make the path to privilege escalation a bit more
:  involved.

Sure, /if/ you decide to run it with superuser privileges.
The point was that if the script demands to be run as root,
you will know, and you can read the script before you run it. 
If the script uses sudo internally, you will not necesarily
know, so you may think that you run it in user space, whereas
in fact it is allowed to jump to superuser space.

If you are sufficiently careful you can reconfigure sudo, and/or run
semi-trusted scripts under a separate under-privileged account.
That's what I call harder.

All of this will not matter if you are either (1) not at all worried
about malware, or (2) so worried about malware that you would 
double- and treble-check everything you run under any user.  For the
users in-between, it is a point worth considering when making a choice 
of how to use sudo and su.

As my personal preference, I would prefer to use sudo only for 
selected routine, low-risk operations, and restrict the blanket 
access for su.  Of course, that has a major downside if you
have sufficiently many sysadmins to make password distribution
difficult.

-- 
:-- Hans Georg

[toc] | [prev] | [next] | [standalone]

#1768

Hans Georg Schaathun <hg@schaathun.net> writes:
> Richard Kettlewell <rjk@greenend.org.uk> wrote:

>> You need to trust that script, even if you use su instead of sudo;
>> all you've done is make the path to privilege escalation a bit more
>> involved.
>
> Sure, /if/ you decide to run it with superuser privileges.

No, I mean if you run a hypothetical program[1] under a uid that you use
to subsequently invoke 'su', then you are trusting that program with
superuser privilege.

[1] Whether a shell script or not; the main difference being that a
    script is easier to review in advance than a compiled program.

-- 
http://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#1769

On Wed, 13 Jul 2011 13:47:53 +0100, Richard Kettlewell
  <rjk@greenend.org.uk> wrote:
:  No, I mean if you run a hypothetical program[1] under a uid that you use
:  to subsequently invoke 'su', then you are trusting that program with
:  superuser privilege.

In what way?

OK.  The programme could start a new shell with different path and/or
logging, and if I don't notice that the shell is different I am lost.

Do you have something simpler?

-- 
:-- Hans Georg

[toc] | [prev] | [next] | [standalone]

#1773

Hans Georg Schaathun <hg@schaathun.net> writes:
> Richard Kettlewell <rjk@greenend.org.uk> wrote:

>> No, I mean if you run a hypothetical program[1] under a uid that you use
>> to subsequently invoke 'su', then you are trusting that program with
>> superuser privilege.
>
> In what way?
>
> OK.  The programme could start a new shell with different path and/or
> logging, and if I don't notice that the shell is different I am lost.
>
> Do you have something simpler?

As you suggest it could start a stunt shell instead of exiting.  It
could modify your .profile to alias su to something evil (or to add
logging etc).  It could ptrace your shell (including shells in other
login sessions!) and invisibly change the meaning of 'su' that way.

I've probably missed some possibilities.


...when I said it was easier to review scripts I'd forgotten that it's
common for software to come with build scripts 10,000 or more lines
long.

-- 
http://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#1766

Hans Georg Schaathun writes:
> If you use sudo, it is difficult to prevent a semi-trusted script, say
> an install script, from running sudo without your noticing.

From the sudoers man page:

requiretty   If set, sudo will only run when the user is logged in
             to a real tty.  When this flag is set, sudo can
             only be run from a login session and not via
             other means such as cron(8) or cgi-bin scripts.
             This flag is off by default.

This should be on by default.
-- 
John Hasler 
jhasler@newsguy.com
Dancing Horse Hill
Elmwood, WI USA

[toc] | [prev] | [next] | [standalone]

#1770

On Wed, 13 Jul 2011 07:37:03 -0500, John Hasler
  <jhasler@newsguy.com> wrote:
:  Hans Georg Schaathun writes:
: > If you use sudo, it is difficult to prevent a semi-trusted script, say
: > an install script, from running sudo without your noticing.
: 
:  From the sudoers man page:
: 
:  requiretty   If set, sudo will only run when the user is logged in
:               to a real tty.  When this flag is set, sudo can
:               only be run from a login session and not via
:               other means such as cron(8) or cgi-bin scripts.
:               This flag is off by default.
: 
:  This should be on by default.

Yes, but that does not prohibit sudo run from within a script run from
a tty.  (Judging from the quoted documentation.)  I wonder what they
mean by a real tty.  After all /real/ real tty are hardly every used
these days :-)

-- 
:-- Hans Georg

[toc] | [prev] | [next] | [standalone]

#1771

Hans Georg Schaathun wrote:
> On Wed, 13 Jul 2011 07:37:03 -0500, John Hasler
>   <jhasler@newsguy.com> wrote:
> :  Hans Georg Schaathun writes:
> : > If you use sudo, it is difficult to prevent a semi-trusted script, say
> : > an install script, from running sudo without your noticing.
> : 
> :  From the sudoers man page:
> : 
> :  requiretty   If set, sudo will only run when the user is logged in
> :               to a real tty.  When this flag is set, sudo can
> :               only be run from a login session and not via
> :               other means such as cron(8) or cgi-bin scripts.
> :               This flag is off by default.
> : 
> :  This should be on by default.
> 
> Yes, but that does not prohibit sudo run from within a script run from
> a tty.  (Judging from the quoted documentation.)  I wonder what they
> mean by a real tty.  After all /real/ real tty are hardly every used
> these days :-)
> 
I think you will find that in order to run as a daemon a process has to 
disconnect stdin  and redirect stdout/stderr in some way.

I believe processes that are not so disconnected are deemed to have a 
'tty' of some sort attached..a 'controlling tty'  is a phrase dredged up 
from the past..  and therefore is deemed to be under some form of user 
control..I think this shows up in the process table, too.



This is all hazy and from long ago, so take it as a guide only.

[toc] | [prev] | [next] | [standalone]

#1772

On Wed, 13 Jul 2011 14:35:29 +0100, The Natural Philosopher
  <tnp@invalid.invalid> wrote:
:  I think you will find that in order to run as a daemon a process has to 
:  disconnect stdin  and redirect stdout/stderr in some way.
: 
:  I believe processes that are not so disconnected are deemed to have a 
:  'tty' of some sort attached..a 'controlling tty'  is a phrase dredged up 
:  from the past..  and therefore is deemed to be under some form of user 
:  control..I think this shows up in the process table, too.

I think the terms `tty' and `controlling tty' would be fairly well
understood to include so-called pseudo-ttys (/dev/pty*).
A real tty in my book, would not include a pty.

-- 
:-- Hans Georg

[toc] | [prev] | [next] | [standalone]

#1774

Hans Georg Schaathun <hg@schaathun.net> writes:
> The Natural Philosopher <tnp@invalid.invalid> wrote:
>> I think you will find that in order to run as a daemon a process has to 
>> disconnect stdin  and redirect stdout/stderr in some way.
>> 
>> I believe processes that are not so disconnected are deemed to have a 
>> 'tty' of some sort attached..a 'controlling tty'  is a phrase dredged up 
>> from the past..  and therefore is deemed to be under some form of user 
>> control..I think this shows up in the process table, too.
>
> I think the terms `tty' and `controlling tty' would be fairly well
> understood to include so-called pseudo-ttys (/dev/pty*).
> A real tty in my book, would not include a pty.

The test performed is to attempt to open /dev/tty and terminate if that
fails.  This will succeed only if the process has a controlling
terminal.

As a security measure I suspect it's pointless in standard
configurations; no privilege is required to create a terminal.

-- 
http://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#1686

On Thu, 7 Jul 2011 22:35:08 +0200, "Peter J. Holzer"
<hjp-usenet2@hjp.at> wrote:

>Aragorn <stryder@telenet.be.invalid> schrieb:
>> On Tuesday 05 July 2011 09:52 in comp.os.linux.misc, JohnT enlightened 
>
>> By consequence, an unprivileged user who is listed in "/etc/sudoers" and 
>> whose account gets compromised - e.g. by an easy-to-guess password - can 
>> easily be exploited to gain root privileges.
>
>If an account which regulary invokes su is compromised, it is trivial to
>compromise the root account, too (unless the user is very very careful -
>but then his normal account probably isn't compromised in the first
>place). Sudo doesn't make this much easier. Used properly, it makes it
>harder (because the compromised account doesn't have unrestricted root
>access).

How so, unless they know the root password?

>That said, I don't particularly like sudo. IMO it is too complex for
>what it does (and security problems do crop up from time to time).

And it can be a pain running complex shell commands in Ubuntu that
need to be run as root.
-- 
(\__/)  M.
(='.'=) Due to the amount of spam posted via googlegroups and
(")_(") their inaction to the problem. I am blocking some articles
posted from there.  If you wish your postings to be seen by
everyone you will need use a different method of posting.

[toc] | [prev] | [next] | [standalone]

#1693

On 2011-07-08 07:53, Mark <i@dontgetlotsofspamanymore.invalid> wrote:
> On Thu, 7 Jul 2011 22:35:08 +0200, "Peter J. Holzer"
><hjp-usenet2@hjp.at> wrote:
>
>>Aragorn <stryder@telenet.be.invalid> schrieb:
>>> On Tuesday 05 July 2011 09:52 in comp.os.linux.misc, JohnT enlightened 
>>
>>> By consequence, an unprivileged user who is listed in "/etc/sudoers"
>>> and whose account gets compromised - e.g. by an easy-to-guess
>>> password - can easily be exploited to gain root privileges.
>>
>>If an account which regulary invokes su is compromised, it is trivial to
>>compromise the root account, too (unless the user is very very careful -
>>but then his normal account probably isn't compromised in the first
>>place).
>
> How so, unless they know the root password?

See my reply to Aragorn.

>>That said, I don't particularly like sudo. IMO it is too complex for
>>what it does (and security problems do crop up from time to time).
>
> And it can be a pain running complex shell commands in Ubuntu that
> need to be run as root.

sudo zsh

	hp

[toc] | [prev] | [next] | [standalone]

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

Back to top | Article view | comp.os.linux.misc

csiph-web