Unix Programming - We need a decent role based way to get backup privilleges

Author

We need a decent role based way to get backup privilleges

Joerg Schilling

2004-05-11, 5:40 pm

I believe it's time to rethink access methods in UNIX.

While more than 20 years ago, UNIX architects did a lot when
designing access permissions, they forgot about backups and
implemented backups in a real ugly quick and dirty hack
called ufsdump. Note that ufsdump reads the raw disk device,
bypassing all clean access layers.

Backups done by ufsdump either need root access as you would
need with a clean backup design that honors layering, or it
gets the permission by bypassing all UNIX access control in case
the disk device is readable by a non root user.

Now that it has been proven that clean backup implemenataions
like "star" that honor layering can do anything that ufsdump
may do and in addition be much faster than ufsdump, I believe it't
time to change the mind and find a way to allow a non-root user
to run backups by accessing the filesystem cleanly through
the OS FS implementation.

What would need is a RBAC way to tell the filesystem code in the
kernel that a specific application should have the permission
to read all files.

Hare is a first idea to be discussed:

It could be done by introducing a "backup" user and a RBAC
entry that tells pfexec to run a backup program like star under
the usr id "backup" in case it has been called by a person who
has the permission to do backups. If star detects that it is
run under uid "backup", it could issue a syscall that requests
read access to all files. The kernel would check the uid of the
running process and in case it is "backup", grant read access
to all files.

--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni) If you don't have iso-8859-1
schilling@fokus.fraunhofer.de (work) chars I am J"org Schilling
URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Casper H.S. Dik

2004-05-11, 5:40 pm

js@cs.tu-berlin.de (Joerg Schilling) writes:

>It could be done by introducing a "backup" user and a RBAC
>entry that tells pfexec to run a backup program like star under
>the usr id "backup" in case it has been called by a person who
>has the permission to do backups. If star detects that it is
>run under uid "backup", it could issue a syscall that requests
>read access to all files. The kernel would check the uid of the
>running process and in case it is "backup", grant read access
>to all files.

How does that work over NFS?

In Solaris 10, using file_dac_read and file_dac_search privileges would
get you there for local files.

Casper

joe durusau

2004-05-11, 5:40 pm

"Casper H.S. Dik" wrote:

> js@cs.tu-berlin.de (Joerg Schilling) writes:
>
>
> How does that work over NFS?
>
> In Solaris 10, using file_dac_read and file_dac_search privileges would
> get you there for local files.
>
> Casper

I think that the O.P. is neglecting the problem that if I can run backup to
a
removable device as a non-priv. user, then I have access to all repeat all
the information on the system. This is not a particularly good thing,
especially
for things like banking, medical systems, etc.

Speaking only for myself,

Joe Durusau

phn@icke-reklam.ipsec.nu

2004-05-11, 5:40 pm

In comp.unix.internals Joerg Schilling <js@cs.tu-berlin.de> wrote:

> I believe it's time to rethink access methods in UNIX.

> While more than 20 years ago, UNIX architects did a lot when
> designing access permissions, they forgot about backups and
> implemented backups in a real ugly quick and dirty hack
> called ufsdump. Note that ufsdump reads the raw disk device,
> bypassing all clean access layers.

> Backups done by ufsdump either need root access as you would
> need with a clean backup design that honors layering, or it
> gets the permission by bypassing all UNIX access control in case
> the disk device is readable by a non root user.

How utterly wrong. BSD 'operator' has read access to raw-disks
and may consequently perform backup using 'dump'

> Now that it has been proven that clean backup implemenataions
> like "star" that honor layering can do anything that ufsdump
> may do and in addition be much faster than ufsdump, I believe it't
> time to change the mind and find a way to allow a non-root user
> to run backups by accessing the filesystem cleanly through
> the OS FS implementation.

See this as a limitation that a utility that reads files
"from above" has to obey ACL and permissions, whereas a utility
that reads from "below" ( like dump) can do full backups
without needing permissions. In addition "file access times"
are not corrupted.

> What would need is a RBAC way to tell the filesystem code in the
> kernel that a specific application should have the permission
> to read all files.

Seems like a security risk to mee.

> Hare is a first idea to be discussed:

> It could be done by introducing a "backup" user and a RBAC
> entry that tells pfexec to run a backup program like star under
> the usr id "backup" in case it has been called by a person who
> has the permission to do backups. If star detects that it is
> run under uid "backup", it could issue a syscall that requests
> read access to all files. The kernel would check the uid of the
> running process and in case it is "backup", grant read access
> to all files.

Seems to me a complicated way that introduces yet another
security hazard. Either you trust root or not. If you don't
trust root there is no where to go... Protecting the raw-devices
in contrast means to guard a simple mechanism that is proven
and well-understood and exists in all forms of un*x

> --
> EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
> js@cs.tu-berlin.de (uni) If you don't have iso-8859-1
> schilling@fokus.fraunhofer.de (work) chars I am J"org Schilling
> URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

--
Peter Håkanson
IPSec Sverige ( At Gothenburg Riverside )
Sorry about my e-mail address, but i'm trying to keep spam out,
remove "icke-reklam" if you feel for mailing me. Thanx.

Joerg Schilling

2004-05-11, 5:40 pm

In article <c7qg4a$2thm$2@nyheter.ipsec.se>, <phn@icke-reklam.ipsec.nu> wrote:

>
>How utterly wrong. BSD 'operator' has read access to raw-disks
>and may consequently perform backup using 'dump'

'ufsdump' is utterly wrong (because it breaks the layering model
and accesses file system data the wrong way) and it is incredibly
slow compared to "star"

ftp://ftp.berlios.de/pub/star/alpha/

Circumventing the UNIX security model by accessing the raw disk
is just wrong.

>
>See this as a limitation that a utility that reads files
>"from above" has to obey ACL and permissions, whereas a utility
>that reads from "below" ( like dump) can do full backups
>without needing permissions. In addition "file access times"
>are not corrupted.

A decent OS is able to grant the Backup Operator the rights he needs
in a decent way and not by just allowing him to circumvent the security
model. On a decent OS, you may tell the OS not to modify
"file access times" when a backup is done.

Star is already able to tell Solaris not to modify the "file access times"
if it is run as root. Unfortunately, the Sun RBAC privileges(5) model
does not yet include a privillege tag for allowing this to non-root
users.

>
>Seems like a security risk to mee.

It is a smaller security risk than the outdated UNIX dump model implies.

>Seems to me a complicated way that introduces yet another
>security hazard. Either you trust root or not. If you don't
>trust root there is no where to go... Protecting the raw-devices
>in contrast means to guard a simple mechanism that is proven
>and well-understood and exists in all forms of un*x

It is a way to _limit_ the possible security hazard by creating
a decent security mode.

--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni) If you don't have iso-8859-1
schilling@fokus.fraunhofer.de (work) chars I am J"org Schilling
URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Casper H.S. Dik

2004-05-11, 5:40 pm

phn@icke-reklam.ipsec.nu writes:

>How utterly wrong. BSD 'operator' has read access to raw-disks
>and may consequently perform backup using 'dump'

Which uses a particular group to access the raw disks (on Solaris, this
is group "sys"; on BSD it is *group* operator, IIRC)

>See this as a limitation that a utility that reads files
>"from above" has to obey ACL and permissions, whereas a utility
>that reads from "below" ( like dump) can do full backups
>without needing permissions. In addition "file access times"
>are not corrupted.

There are situations, of course, were data is labeled and other
access mechanisms apply and backdoors are not allowed.

(Another question is to which extends traditional backups are
the proper paradigm; prices of disks come down harder than tape
and "remote mirroring" might be quicker, more cost-effective and
more usable then traditional backups)

[vbcol=seagreen]
>Seems like a security risk to mee.

It is not very different from a user who has privileges (specific group)
to read the raw disk files.

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

Michael Vilain

2004-05-12, 2:35 am

In article <c7qhfs$d3u$1@news.cs.tu-berlin.de>,
js@cs.tu-berlin.de (Joerg Schilling) wrote:

> In article <c7qg4a$2thm$2@nyheter.ipsec.se>, <phn@icke-reklam.ipsec.nu>
> wrote:
>
>
> 'ufsdump' is utterly wrong (because it breaks the layering model
> and accesses file system data the wrong way) and it is incredibly
> slow compared to "star"
>
> ftp://ftp.berlios.de/pub/star/alpha/

Forgive me if this sounds self-serving. You _are_, after all, the
author of star.

"A poet who reads his verse in public may have other nasty habits"
-- Lazarus Long

>
> Circumventing the UNIX security model by accessing the raw disk
> is just wrong.
[snip]
>
> A decent OS is able to grant the Backup Operator the rights he needs
> in a decent way and not by just allowing him to circumvent the security
> model. On a decent OS, you may tell the OS not to modify
> "file access times" when a backup is done.
>
> Star is already able to tell Solaris not to modify the "file access times"
> if it is run as root. Unfortunately, the Sun RBAC privileges(5) model
> does not yet include a privillege tag for allowing this to non-root
> users.
>
[snip]

> It is a smaller security risk than the outdated UNIX dump model implies.
>
[snip]

> It is a way to _limit_ the possible security hazard by creating
> a decent security mode.

Sounds like you want the VMS security model with multiple privileges for
doing this type of thing. I think that's why the VMS developers did
that--they saw root on UNIX and started with a much more robust security
model. There's a specific privilege called OPERATOR that allows R/O
access to all files so that anyone running VMS BACKUP can backup a
filesystem.

Pissing and moaning about the way things _should be_ ain't gonna get
them changed. What about the 20 years worth of stuff that will break?
What was your point of the original post, other than to vent?

--
DeeDee, don't press that button! DeeDee! NO! Dee...

Jay Lessert

2004-05-12, 4:58 pm

js@cs.tu-berlin.de (Joerg Schilling) wrote in message news:<c7qhfs$d3u$1@news.cs.tu-berlin.de>...
> Star is already able to tell Solaris not to modify the "file access times"
> if it is run as root. Unfortunately, the Sun RBAC privileges(5) model
> does not yet include a privillege tag for allowing this to non-root
> users.

Joerg,

Last time I looked, if one writes atime, ctime gets changed.
Is that what star does? If so, that does not really fulfill
Peter's "no-touch" backup concern.

This particular problem disappears, though, if you only back up
snapshots, never live file systems.

I agree with the need for a "third way" of file system access for
backups. Now, per Casper's suggestion, I need to go read about
file_dac_read in the RBAC documentation, and see if it already
exists (for Solaris).

-Jay-

Jay Lessert

2004-05-12, 4:58 pm

Darren Dunham

2004-05-12, 4:58 pm

In comp.unix.solaris Jay Lessert <jayl-news@accelerant.net> wrote:
> js@cs.tu-berlin.de (Joerg Schilling) wrote in message news:<c7qhfs$d3u$1@news.cs.tu-berlin.de>...
[vbcol=seagreen]
> Joerg,

> Last time I looked, if one writes atime, ctime gets changed.
> Is that what star does? If so, that does not really fulfill
> Peter's "no-touch" backup concern.

Only if you assume that you need to write atime. I believe what he's
saying is that you can read the files without having atime update in the
first place, so you don't have to write it back.

> This particular problem disappears, though, if you only back up
> snapshots, never live file systems.

True.

--
Darren Dunham ddunham@taos.com
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >

those who know me have no need of my name

2004-05-13, 4:34 am

in comp.unix.internals i read:

>What about the 20 years worth of stuff that will break?

why would anything break? surely a solution which did break existing
programs would not be a successful candidate. now, should there be a
new open mode bit postulated which in combination with the uid and/or
program's privileges allows files to be accessed without updating the
atime and would succeed even if the permissions or acl's would other-
wise normally disallow -- such a thing might be workable, and perhaps
to the extent that ieee and the open group would even consider it, if
there were sufficient interest.

--
a signature

Joerg Schilling

2004-05-13, 11:31 am

In article <7109f92b.0405121214.410bf7cf@posting.google.com>,
Jay Lessert <jayl-news@accelerant.net> wrote:
>js@cs.tu-berlin.de (Joerg Schilling) wrote in message news:<c7qhfs$d3u$1@news.cs.tu-berlin.de>...
[vbcol=seagreen]
>Last time I looked, if one writes atime, ctime gets changed.
>Is that what star does? If so, that does not really fulfill
>Peter's "no-touch" backup concern.

If you run star as non-root, calling "star -c -atime ..."
will cause ctime to be updated. If you do the same thing as root
on a local filesystem, none of the time gets changed.

Star uses an interface that is present in Solaris since at least 10 years
and that has been designed for clean backups that do not break
access layering (like ufsdump does).

Even if there are people who believe that is is OK for ufsdump to
work the way it is written, there is still the problem that
you would need a separate backup progran for every new filesystem type.
Doing backups with a high level program like star will allow you to have a
unique backup method for all possible file systems.

>This particular problem disappears, though, if you only back up
>snapshots, never live file systems.

Of course, this is the second way to be able to create a clean backup
without changing the time stamps.

>I agree with the need for a "third way" of file system access for
>backups. Now, per Casper's suggestion, I need to go read about
>file_dac_read in the RBAC documentation, and see if it already
>exists (for Solaris).

And I hope that they will add a "permission" tag that allows to
read a file without changing the time stamps ot that allows to call
ioctl(fd, _FIOSATIME, &atv) as non root user.

--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni) If you don't have iso-8859-1
schilling@fokus.fraunhofer.de (work) chars I am J"org Schilling
URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily