Re: [TOMOYO #7 30/30] Hooks for SAKURA and TOMOYO.

[Casey Schaufler]

--- Stephen Smalley <sds@xxxxxxxxxxxxx> wrote:

> 
> ...
> 
> I think some might argue that the integrity of the data in /etc/shadow
> and your .ssh files is very important, not just their names.

I believe that the key word here is "just". If you go back to
the Orange Book you will see that the combination of the object
and the name by which it is referenced is important. The audit
requirements are most interesting, as they make it clear that
without a relevant name associated with the object an audit
record has no value.

The Orange Book Unix evaluations raised enormous issues regarding
the file system name space. I know that at least two vendors
stated that the name of the object was its device/inode pair and
that the pathname stuff was there strictly for user convenience
and was not security relevent. This is of course hogwash, but
was logically consistant in the context of security policy
documentation. These same vendors had to then make completely
distinct arguments about their audit systems in order to meet
the name identification requirements there.

The question of protections on the object named /etc/passwd came
up time and time again. The notion that /etc/passwd could be a
symlink to /home/smalley/heeheehee really gave evaluators the
whillies. As did the chroot environment, where /roots/crispin/etc/passwd
could magicly become /etc/passwd. One reason that the object
access model is so firmly ingrained is that it allows the
security documentation to wave it's paw and say "bah" when
these questions arise.

> And as
> names are themselves just data contained by directories, the integrity
> of the names is a particular case of the data integrity problem.  And
> ultimately data integrity requires information flow control to preserve.

Good example of my point. The argument is true, and the implications
important, but the conclusion is not satisfactory.

> >     * *Dynamic Access Control:* A special case of the above pertains to
> >       files that may or may not exist. If you don't *have* a /etc/hosts
> >       file, it is still important to have a rule that controls whether
> >       it can be created. This is hard to do in label-based systems,
> >       because the file does not exist to put a label on, so you have to
> >       kludge it by either creating the file with zero length and
> >       labeling it, or by creating more complex policy for the parent
> >       /etc directory, and that's hard given the number of uses for /etc
> >       such as /etc/motd. In a name based scheme, you simply don't
> >       provide write permission to "/etc/hosts" unless you mean it, and
> >       it can be enforced even if such a file does not exist.
> 
> I'd view this as another example of practical or legacy concerns, as it
> wouldn't pose a problem if either of the following were true:
> - /etc was further partitioned into multiple subdirectories (seemingly
> true in an increasing number of cases, so we seem to be moving in that
> direction regardless) so that inheritance from parent directory would
> suffice, or
> - specific programs were used to create or update the individual files
> (true for some of the files in /etc, and generally helpful for ensuring
> proper data formatting and applying basic sanity checks on the content)
> so that the files created by them could be labeled based on the creating
> domain or via appropriate instrumentation of the programs to set the
> attributes (the latter is not fundamentally different than the situation
> for DAC ownership/mode or ACLs).

Yes, a proper design of the administrative data and interfaces
would solve the problem of /etc/passwd right quick. It would not
address the general issue which is assuring that access is controlled
based on the names that people use.

> Also, note that in the case of SELinux, we do have a solution to the
> above situation, namely restorecond, which leverages the kernel's
> inotify mechanism.

Well, I don't see that addressing the case where /etc/passwd is
a symlink unless restorecond is more sophisticated than I understand
it to be (correct me if I'm wrong) and I certainly can't see it
being used on every file on a multiple pedabyte filesystem.

> As an example where the name-based schemes have difficulties with
> "dynamic" data, files created at runtime in /tmp and other shared
> directories often have security-irrelevant names, yet protecting them
> from tampering by others can be very relevant to security.  There the
> attribute-based schemes have the advantage.

Very true.
 
> ...

> The weaknesses from my POV are:
> - no system-wide view of the subjects and objects and thus of the
> policy,
> - no uniform abstraction for handling objects (not everything has a
> pathname), leading to inconsistent or incomplete control,
> - no useful information for runtime objects,
> - forcing policy to be written in terms of individual objects and
> filesystem layout rather than security properties.

These are all legitimate concerns, but it is really hard to say
that they outweigh the value of controlling access to /etc/passwd
by specifying that you want to control access to /etc/passwd.
The real problem lies in the perfectly reasonable but nontheless
untrue assumptions that users, administrators, and developers
make about the relationship between names and objects on *ix
filesystems. The object model is more correct, and the dickins
easier to write kernel code for I might add. The problem is that
the object model is not what is exposed by the syscall interface,
it's the filesystem namespace. I have oft considered an OS (casex?)
that exposes the device/inode pair and leaves all the pathname
stuff to application space, but I doubt it would be popular
because the namespace is riddled with handy features.

We could fix the filesystem namespace, and then the issue would
evaporate, but I think too many people would think it was fixed
in the veterenary sense.


Casey Schaufler
casey@xxxxxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/