Subject: RE: script extensibility I-D

From: "Wallis, David" <[email-masked]>
Date: Tue, 26 Jun 2001 14:59:31 -0500

The important point is that the file must be identified by location or
content, not just by name *before* making decisions as to the security
profile it should enjoy. The agent can store the script somewhere in the
filesystem if necessary, but it needs to record not just the name of the
temporary file, but the inode as well. Then when it goes to pass the file to
the runtime engine, it should pass the open filehandle or the actual bytes
of the file (via stdin) to the runtime engine. (Presumably, if the inode
doesn't match, the agent will refuse to pass it to the runtime engine,
because it's not the same file the agent stored.)

David Wallis

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]]
Technical contributor:
This argument says that stuff retrieved from file systems
can't be trusted unless one can trust every single node in
the path.  The proposal to ship the script via stdin just
shifts the worry about the integrity of all the nodes in the
path from the execution engines to the "agent".  Those scripts
eventually reside on some file system somewhere.  Whether it's
the "agent" reading them or the execution engines doesn't
really change the problem.

If the agent sends a path, it should only send paths it trusts.
If the agent ships a file image, it should only send images of
files it has retrieved using paths it trusts.

Seems like six of one, half-dozen of the other.

 ------------------------------------------------------
 Randy Presuhn          BMC Software, Inc.  1-3141
 [email-masked]  2141 North First Street
 Tel: +1 408 546-1006   San José, California 95131  USA
 ------------------------------------------------------
 My opinions and BMC's are independent variables.
 ------------------------------------------------------

---

From: Frank Strauss <[email-masked]>
Date: 27 Jun 2001 10:49:18 +0200

Hi!

David> The important point is that the file must be identified by
David> location or content, not just by name *before* making decisions
David> as to the security profile it should enjoy. The agent can store
David> the script somewhere in the filesystem if necessary, but it
David> needs to record not just the name of the temporary file, but
David> the inode as well. Then when it goes to pass the file to the
David> runtime engine, it should pass the open filehandle or the
David> actual bytes of the file (via stdin) to the runtime
David> engine. (Presumably, if the inode doesn't match, the agent will
David> refuse to pass it to the runtime engine, because it's not the
David> same file the agent stored.)

You are saying that there is a possibilty that some third foreign
process could intervene by modifying the script file or its file
system meta data after it was put in the file system by the agent and
before the runtime engine opens it. Is this correct?

If yes, let me argue why I think this is not true: As almost any
program on a UNIX system the agent and the runtime system rely on the
file access permission attributes that are supported by the file
system. Of course, the directory where the scripts are stored for
passing them to the runtime system and all parent directories have to
have to appropriate permissions. Appropriate means that only the
superuser and the agent (and optionally other priviledged users) can
write to that directory. So, the assumption is true, that there cannot
be any intervening third party that corrupts the script file.

Let me rephrase Juergen's plea for a concrete description of a
possible expoit: Please describe what an attacker could do to make the
runtime engine execute another script than the one that the agent has
written to the local directory, assuming the attacker would have
unlimited CPU time after the script is stored by the agent and before
it is opened by the runtime engine.

If you will convince me (what I don't expect ;-)), I would not use
inodes, since user space processes should not care about them and they
are not more secure than file names. In fact, then I wouldn't even
trust the runtime engine process because I could not know whether the
program I expect to have started by the execve("/path/to/runtime",
...) call is the right one. ;-)

 -frank

---

From: Heiko Rupp <[email-masked]>
Date: Wed, 27 Jun 2001 12:29:16 +0200

> passing them to the runtime system and all parent directories have to

What about the following scenario:

1) agent writes the file
2) root unmounts the disk where the file is on
3) the runtime opens a file that was hidden by the mountpoint, with a 
totally different content

Here, all permissions are ok and still the result is not as desired.

-- 
Heiko W. Rupp
Project Management
WiredMinds Informationssysteme GmbH
Wilhelmsplatz 11
D-70182 Stuttgart

Email: [email-masked]
Phone: +49 711 49048-232
Fax:   +49 711 49048-111

---

From: Frank Strauss <[email-masked]>
Date: 27 Jun 2001 12:44:19 +0200

Hi!

>> passing them to the runtime system and all parent directories have to

Heiko> What about the following scenario:

Heiko> 1) agent writes the file
Heiko> 2) root unmounts the disk where the file is on
Heiko> 3) the runtime opens a file that was hidden by the mountpoint, with a
Heiko> totally different content

Heiko> Here, all permissions are ok and still the result is not as desired.

The superuser has always permissions to do things that cause a
behaviour that is not expected by others. That's life. I don't regard
things that the superuser does as an attack or their consequences as a
security problem.

 -frank

---

From: Heiko Rupp <[email-masked]>
Date: Wed, 27 Jun 2001 13:57:53 +0200

> things that the superuser does as an attack or their consequences as a

I did not want to imply, that this is a security problem, but point out
a scenario, where a process might not find the file it thinks it is.

---

From: Frank Strauss <[email-masked]>
Date: 27 Jun 2001 14:08:17 +0200

Hi!

>> things that the superuser does as an attack or their consequences as a

Heiko> I did not want to imply, that this is a security problem, but
Heiko> point out a scenario, where a process might not find the file
Heiko> it thinks it is.

Point taken. Thank you.

So, let's see whether there are other ways that are a security problem.

 -frank