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

Groups > comp.unix.programmer > #868 > unrolled thread

Why user can change password?

Back to article view | Back to comp.unix.programmer

Contents

  Why user can change password? Mateusz_madi <madi.czadi@gmail.com> - 2011-06-29 02:44 -0700
    Re: Why user can change password? jt@toerring.de (Jens Thoms Toerring) - 2011-06-29 09:55 +0000
    Re: Why user can change password? Ben Finney <ben+unix@benfinney.id.au> - 2011-06-29 22:36 +1000
      Re: Why user can change password? jt@toerring.de (Jens Thoms Toerring) - 2011-06-29 15:03 +0000
    Re: Why user can change password? John Gordon <gordon@panix.com> - 2011-06-29 14:41 +0000
      Re: Why user can change password? Golden California Girls <gldncagrls@aol.com.mil> - 2011-06-29 18:42 -0700
        Re: Why user can change password? Barry Margolin <barmar@alum.mit.edu> - 2011-06-29 22:29 -0400
        Re: Why user can change password? Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-06-29 22:29 -0400
        Re: Why user can change password? gordonb.h6afl@burditt.org (Gordon Burditt) - 2011-06-29 22:10 -0500
        Re: Why user can change password? Nobody <nobody@nowhere.com> - 2011-06-30 18:10 +0100

#868 — Why user can change password?

Hi, why usre cna change his pasword using passwd if he don't have
access to /etc/shadow ?

Regards,
Madi

[toc] | [next] | [standalone]

#870

Mateusz_madi <madi.czadi@gmail.com> wrote:
> Hi, why usre cna change his pasword using passwd if he don't have
> access to /etc/shadow ?

Because the 'passwd' program has special privileges when it's
running. If you do

> ls -l /usr/bin/passwd 
-rwsr-xr-x 1 root root 42856 2011-02-14 23:11 /usr/bin/passwd

you will notice the 's' instead of an 'x' in the permissions
for the owner of this program (root). This indicates that this
program is 'setuid'-ed, i.e. it will run with the permissions
of the owner of the program instead your more restricted user
permissions. A Google search for 'setuid' will give you a lot
of additional information.
                               Regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

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

#871

Mateusz_madi <madi.czadi@gmail.com> writes:

> Hi, why usre cna change his pasword using passwd if he don't have
> access to /etc/shadow ?

That's an excellent question.

Some programs are allowed to run with the permissions, not of the user
who invoked the progrma, but the permissions of the user and/or group
that owns the program file. These are ‘setuid’ and ‘setgid’ permissions,
respectively.

It's common for the program to be owned by the ‘root’ user, and ‘setuid’
permission means that regardless of the user who runs the program, the
permissions of the program will instead be those of the ‘root’ user.
That's how the ‘/usr/bin/passwd’ program, for example, has permission to
write the ‘/etc/passwd’ and ‘/etc/shadow’ files that aren't writeable by
the account which starts the program.

It's a significant security risk, of course. That's why it's considered
a red flag for a program to have ‘setuid’ or ‘setgid’ permission. Be
very wary of any program which claims to require that; there are very
few legitimate reasons to require that, and the set of programs with
those permissions should be very small on any given host.

-- 
 \       “First things first, but not necessarily in that order.” —The |
  `\                                              Doctor, _Doctor Who_ |
_o__)                                                                  |
Ben Finney

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

#873

Ben Finney <ben+unix@benfinney.id.au> wrote:
> It's common for the program to be owned by the ‘root’ user, and ‘setuid’
> permission means that regardless of the user who runs the program, the
> permissions of the program will instead be those of the ‘root’ user.
> That's how the ‘/usr/bin/passwd’ program, for example, has permission to
> write the ‘/etc/passwd’ and ‘/etc/shadow’ files that aren't writeable by
> the account which starts the program.

> It's a significant security risk, of course. That's why it's considered
> a red flag for a program to have ‘setuid’ or ‘setgid’ permission. Be
> very wary of any program which claims to require that; there are very
> few legitimate reasons to require that, and the set of programs with
> those permissions should be very small on any given host.

Well, that seems to me to be a bit broad a claim. 'setuid' or
'setgid' doesn't equate to root permissions. And there can be
completely legitimate (and not really dangerous) use cases. E.
g. consider a program that needs access to the serial port to
be able to communicate with some attached device. The serial
port device files belong on many systems to the group 'uucp'
or 'dialout'. By 'setgid'-ing the program to that group every
user then can use the serial port via that program. And since
those groups don't have any special permissions no harm can be
done. It's probably even safer this way than to allow full ac-
cess to the serial port by each and every user with whatever
software by making its device file accessible to all users.

                             Regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

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

#872

In <8d6a4a86-6fdf-4183-bfba-5ed322a98195@u28g2000yqf.googlegroups.com> Mateusz_madi <madi.czadi@gmail.com> writes:

> Hi, why usre cna change his pasword using passwd if he don't have
> access to /etc/shadow ?

Because the "passwd" program has special permissions.

Most programs, for example "ls" or "cp", run as you.  That is, when you
run them, they have permission to do anything you could do.

But the "passwd" program is different.  It runs as root, and has permission
to do anything root could do (which is everything.)

-- 
John Gordon                   A is for Amy, who fell down the stairs
gordon@panix.com              B is for Basil, assaulted by bears
                                -- Edward Gorey, "The Gashlycrumb Tinies"

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

#874

On 6/29/11 7:41 AM, John Gordon wrote:
> It runs as root, and has permission
> to do anything root could do (which is everything.)
> 

I was under the impression that a program running as root was limited and
can't do everything.  An example being ignoring a kill, or reading and
writing any address in any process space.  These are things a driver can do
as a driver is allowed to run CPU privileged instructions.  Am I wrong and
a program running as root can run CPU privileged instructions?

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

#875

In article <iugk9c$2e1$1@speranza.aioe.org>,
 Golden California Girls <gldncagrls@aol.com.mil> wrote:

> On 6/29/11 7:41 AM, John Gordon wrote:
> > It runs as root, and has permission
> > to do anything root could do (which is everything.)
> > 
> 
> I was under the impression that a program running as root was limited and
> can't do everything.  An example being ignoring a kill, or reading and
> writing any address in any process space.  These are things a driver can do
> as a driver is allowed to run CPU privileged instructions.  Am I wrong and
> a program running as root can run CPU privileged instructions?

It would be more accurate to say that it is not generally restricted by 
system calls.  Filesystem permissions are ignored, any there are a 
number of system calls that ONLY allow use by root.

It's not running in privileged mode on the CPU, but it has access to 
load drivers and modify kernel memory, so it can create ways for it to 
get into privileged mode running any code it wants.

In some cases, it may have to take indirect routes to exercising its 
power.  For instance, some flavors of Unix have "immutable" files, which 
can't be written even by root.  But root can turn off the immutable flag.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

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

#876

On 6/29/2011 9:42 PM, Golden California Girls wrote:
> On 6/29/11 7:41 AM, John Gordon wrote:
>> It runs as root, and has permission
>> to do anything root could do (which is everything.)
>>
>
> I was under the impression that a program running as root was limited and
> can't do everything.  An example being ignoring a kill, or reading and
> writing any address in any process space.  These are things a driver can do
> as a driver is allowed to run CPU privileged instructions.  Am I wrong and
> a program running as root can run CPU privileged instructions?

     It can't ignore SIGKILL, no[*].  It also can't cure cancer,
repeal the laws of thermodynamics, or sprinkle maple syrup on the
DIMM's.  So John was wrong: A root process cannot in fact do
"everything."

     As for privileged instructions, I see no reason why a root
process couldn't run them.  It'd probably need to jump through
some hoops first, but hoops don't deter root.

     [*] Well, it could open /dev/kmem or equivalent, find the
spot where SIGKILL is delivered, and overwrite the instructions
to prevent the delivery.  That might be an effective substitute.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

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

#877

>> It runs as root, and has permission
>> to do anything root could do (which is everything.)
>> 
> 
> I was under the impression that a program running as root was limited and
> can't do everything.  

A user-level program is still limited by being a user-level program.
However, some standard drivers act as loopholes that can give a
root user-level program almost the privileges of the kernel.

On many systems, a user-level (virus?) program running as root can
(write, compile and ) install new drivers into a running kernel.
Or remove existing ones and replace them.  (I've done that a lot
trying to extend a driver to handle another device similar to the
ones it already handles).  Or replace the kernel entirely, then
reboot.  (I do system version upgrades fairly often, too.) Some
features such as immutable files or a hardware write-protected root
filesystem can prevent this.  Virtualization is supposed to limit
the damage to one virtual machine.

> An example being ignoring a kill, or reading and

Do you mean ignoring "kill -9"?  Any not particularly privileged user
process can ignore SIGHUP or SIGINT, among others.

> writing any address in any process space.  

In some implementations, the "/dev/kmem" and "/dev/mem" drivers
confer on "ps" the right to *read* any address in any process space
by virtue of "ps" being setgid "sys".  (With "root", you get
*read/write*.) With this privilege generally doesn't come good
locking, so on a heavily swapping system "ps" can intermittently
come up with garbage on these systems.  "/dev/io" sometimes provides
enough of a hook so a user-level process alone can act as a driver.

With later implementations, "/dev/proc" plus some debugger
implementations may provide cleaner and less error-prone ways to
read and write any process address space.

> These are things a driver can do
> as a driver is allowed to run CPU privileged instructions.  Am I wrong and
> a program running as root can run CPU privileged instructions?

If it installs its own drivers, yes.  If it can use existing drivers for
its purposes, yes.

Reading and writing files does not require CPU privileged instructions
beyond what any disk I/O does, and if you ask for disk i/o through
the filesystem, you can usually find *some* disk *somewhere* you
can write to (such as in /tmp ).  Writing to /etc/shadow does not
require CPU instructions more privileged than writing to a file
under /tmp.  They are likely both just disk blocks on the same disk.
It's up to the filesystem code to limit who gets to write what
files.

On some systems, the /dev/io driver works such that opening it
confers on the process the right to *directly* run certain priviliged
CPU instructions related to I/O.  The difference between this and
calling a driver to do it is mostly a difference in efficiency.  At
the CPU level, "privileged instruction" is not necessarily an
all-or-nothing issue.

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

#878

On Wed, 29 Jun 2011 18:42:04 -0700, Golden California Girls wrote:

> On 6/29/11 7:41 AM, John Gordon wrote:
>> It runs as root, and has permission
>> to do anything root could do (which is everything.)
>> 
> 
> I was under the impression that a program running as root was limited and
> can't do everything.  An example being ignoring a kill, or reading and
> writing any address in any process space.  These are things a driver can do
> as a driver is allowed to run CPU privileged instructions.  Am I wrong and
> a program running as root can run CPU privileged instructions?

User-space programs are still limited by hardware-based protection
mechanisms (user-mode/ring-3/etc versus supervisor-mode/ring-0/etc),
although they may be able to circumvent these mechanisms by
creating and loading kernel modules.

Processes owned by "root" (i.e. UID 0) are special insofar as explicit,
software-based permission checks normally succeed if the UID is 0,
regardless of any other factors which are normally taken into account
(e.g. file permissions or ownership).

Some Unix systems (e.g. *BSD) have a "securelevel" mechanism which
disables any feature which can be used to circumvent the normal security
mechanisms, e.g. loading kernel modules, direct access to memory or I/O
ports, etc. Typically, the securelevel starts at zero (no restriction);
once all kernel modules have been loaded and the hardware has been
initialised, the securelevel is increased. After this point, the security
mechanisms cannot be bypassed even by root, and the securelevel cannot be
decreased (other than by a reboot).

[toc] | [prev] | [standalone]

Back to top | Article view | comp.unix.programmer

csiph-web