sample 5.3 based trusted os ;-)

[Robert Watson]

On Sat, 22 Jan 2005, Ilmar S. Habibulin wrote:

> On Fri, 21 Jan 2005, Martin Englund wrote:
> 
> > We use a system call called resolvepath(2)[1] on all filenames before they
> > end up in the audit tail, so all soft links gets resolved (the path token)
> I heard some rumors, that sun is giving solaris sources for free. Is it
> true and if it is, what are conditions? Maybe solaris sources help to make
> vn_fullpath() more reliable or develop new subsystem

One of the reasons I ask about the degree of reliability is to try and
understand how much we need to do to improve the current level of
reliability.  Right now, vn_fullpath() is "for informational purposes"
inside the kernel, but not guaranteed to produce a usable name.
Specifically, it inspects the name cache to attempt to reconstruct a path
to a vnode -- this has the following limitations:

- Not all file systems use the name cache, so it fails for fairly key file
  systems, such as devfs.  These synthetic file systems don't use the name
  cache because (a) there's no real performance benefit to doing so, and
  (b) they play games with synthetic name spaces.

- Files with more than one name return the first matching path in the
  name cache -- for example, you may not get the name you expect if a file
  is hard-linked to a place you don't expect.  I.e., a user has
  hard-linked /usr/sbin/sshd to /usr/tmp/sshd.

- The name cache can drop intermediate name entries under vnode cache
  pressure, which means not all referenced vnodes have a complete path in
  the cache, resulting in failure when attempting to determine one.

- For distributed file systems, a name cache could contain quite stale
  data -- for example, if you use a name cache with NFS, renames of
  objects can occur without a cache invalidation.

There are some other implications also regarding things like trying to
find the name of an object after you unlink it, etc.  Subject to the
limitations of a BSD/Sun-style VFS, some of these can be addressed
relatively easily:

- Add VFS_GETPATH(), VOP_GETPATH(), or some similarly named file system
  entry point that queries the file system to generate a name for an
  object relative to its root.  For synthetic file systems, this is
  probably easily implemented, and would address what to do about the fact
  that they often don't use the name cache.  This might also be used in
  the event intermediate names fall out of the name cache.

- Consider not dropping intermediate nodes from the name cache -- this is
  useful from a performance perspective, so maybe only make this decision
  when running with Audit.  In the non-audit case, the intermediate nodes
  can result in a non-LRU handling of the vnode cache and could hurt
  performance.  However, with audit on pathnames enabled, it will
  presumably help performance since you're going to need those nodes
  anyway.

- Even without dropping intermediate nodes, there are still situations
  where a pathname to a valid named object can be invalidated leaving no
  valid names in the cache, even though there are valid names.  For
  example, a hard linked file appears in two directories, one of which has
  been looked up since boot, and the other has not.  When the looked up
  path is unlinked, there's still a valid path to the object, and the
  object can still be "inuse", but the name cache can't help you.  In this
  case presumably file systems supporting this scenario should support a
  potentially more expensive VOP_GETPATH() that searches for a path to the
  object.  Note that in UFS, this could be quite an expensive operation
  since there are not parent back-pointers from file leaf nodes -- you
  might have to search every directory in the file system!

Hence the question about degree of reliability offered by the Sun
(reference) implementation of BSM audit: if it provide relatively weak
guarantees in nasty edge cases (such as the last one above), then there's
no reason for us to huge amounts of trouble to produce a stronger
guarantee since presumably current analysis and IDS tools will know about
the weakness and how to handle it.  On the other hand, if the Sun
implementation really does guarantee it will produce a quite useful path
to an object in use, even in nasty edge cases, we presumably need to do
the same, as "Oops, I couldn't find a path" is not an acceptable thing to
find in a log file.

Note that in Darwin, Apple has an easier time with this, as their "most
supported" file systems (HFS+, AppleShare) really do have a notion of
canonical names for objects.

Robert N M Watson

To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message