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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Stephen Smalley wrote:
On Sun, 2008-04-13 at 19:05 -0700, Crispin Cowan wrote:
Things that pathname-based access control is good at:

    * *System Integrity:* Many of the vital components of a UNIX system
      are stored in files with Well Known Names such as /etc/shadow,
      /var/www/htdocs/index.html and /home/crispin/.ssh/known_hosts. The
      contents of the actual data blocks is less important than the
      integrity of what some random process gets when it asks for these
      resources by name. Preserving the integrity of what responds to
      the Well Known Name is thus easier if you restrict access based on
      the name.
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 understand how the confidentiality of secrets like the contents of /etc/shadow and your .ssh files is important, but how can the integrity of these data objects be important? Back them up if you care ...

  And as
names are themselves just data contained by directories, the integrity
of the names is a particular case of the data integrity problem.
That's just access control for the containing directory, and/or access control to the raw partition, which is also controlled by name-based access control to /dev

  And
ultimately data integrity requires information flow control to preserve.
You've argued that before, and I've never been convinced. Rather, it looked a lot like a stretched definition trying really hard to turn integrity into an information flow problem.The most information flow that I will buy in the integrity problem is taint analysis of software inputs; that software should validate inputs before acting on it.

    * *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
If you want to move this particular benefit to the "practical" bucket, I have no issue with that. It is a core part of the name-based argument that it is a practical solution for system administrators who experience the system through names.

- 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).
Security architecture for a clean&pure architecture are an interesting problem, but certainly are not the LSM problem.

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.
IMHO that is a slow and racy solution. If one applied the kind of standards that AppArmor is being asked to pass to restorecond, it would have a tough time too.

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,
Presumably you mean that the name is not meaningfully predictable with respect tot he application. Yes, sometimes this is a problem, and AppArmor doesn't presently deal with it well.

 yet protecting them
from tampering by others can be very relevant to security.  There the
attribute-based schemes have the advantage.
John Johansen has some designs he has been working on to let an AA profile require a UID match as well as a name match. To the extent that file ownership is a kind of label, this is a small step towards a hybrid model that leverages the strengths of both name and label based access controls.

    * *Ad Hoc Generalization:* Label-based access control generalizes
      policy in that the policy treats all files and resources that
      share a label the same. If you want to make a new generalization
      that encompasses *part* of the files that share a label, but *not
      all* of those files, then you have to "split the label", relabel
      the file system, and revise the policy accordingly. Name-based
      access control lets you create ad hoc generalizations, so that
      *my* policy can grant access to "/var/www/*.pl" without regard to
      whatever labels or rules some other policy has applied to the same
      directory tree.
We might argue about whether ad hoc policy writing is the best approach.
Another way of saying "ad hoc policy writing" is "incremental policy development."

If you can anticipate everything you need in your data center and get it right ahead of time, then you don't need ad hoc policy. If circumstances change on you and you need to adapt, then your policy is necessarily ad hoc.

Regardless, the corresponding weakness here for the path-based schemes
is that they force you into writing policy in terms of the filesystem
layout and names, which may have little or no bearing on the actual
security characteristics of the files.
I assert that the pathname has a strong correspondence to the integrity sensitivity of the file, and a weaker correspondence to the confidentiality sensitivity of the file, e.g. a backup copy of your actual /etc/shadow file is still sensitive if it gets disclosed to someone intent on password cracking.

This is not a severe problem for AppArmor in practice because of the default-deny nature of the policy: only grant read access to the files you intend to allow to be read. It is fairly difficult to accidentally disclose a file in an AppArmor policy unless you engage in really sloppy practice like dropping copies of sensitive files in publicly readable places like /tmp

    * *Familiar Interface:* Administrators are accustomed to
      administering the box in terms of the names of the files that
      matter. A name-based policy is therefore somewhat more familiar
      than a policy with label abstractions, where they then have to go
      look at the restorecon file to discover what files will/should
      have what labels.
restorecon /path/to/file doesn't require the user to deal with anything
other than a pathname.
Yes it does. To understand your security policy, you have to understand both the SELinux policy about labels & types and which are allowed to access each other, and also the restorecon specification that determines what labels will be applied to which files.

    * *Practical Concerns:* Not all file systems support labels, and so
      label-based schemes become coarse grained when they run into them.
      Name based schemes remain granular when specifying access down
      into the internals of such file systems. Legacy Linux file systems
      like ext2 don't matter much any more, but persistent file systems
      that will never have label support include NFSv3 file systems
      (nearly every Network Appliance NAS server out there) and FAT32
      file system (most every USB storage device).
At present this is a limitation, although we do support per-mount
labeling of such filesystems, which is really all we can guarantee in
terms of protection anyway
That's what I meant by granular: you get access to the whole NFS mount, or none of it.

 - anything further is misleading as the
server or device won't ensure any finer grained separation for us.
I don't understand this issue. The enforcement here is t contain the program executing on the NFS *client* to permit it to only mangle the parts of the NFS mount that you want it to mangle. That the server won't enforce anything for you is irrelevant when the threat is the confined application.

A lot of what's going on is the duality of the one:many relationships between labels and names:

    * Labels: one label represents many files
          o this property is why ad hoc generalization fails in label
            based systems
    * Names: many names can represent a single file
          o This property is why deny rules fail in name based systems

Therefore, I am not claiming name-based access controls to be the ultimate. Rather, there are duals for all of the above that induce circumstances where label-based systems are superior. Each class of system has strengths and weaknesses. These are name-based strengths.

The weaknesses from my POV are:
- no system-wide view of the subjects and objects and thus of the
policy,
... and no *requirement* to construct a system-wide consistent view of security policy.

- no uniform abstraction for handling objects (not everything has a
pathname), leading to inconsistent or incomplete control,
*Strawman* argument: AppArmor doesn't try to apply pathnames to everything, just the file system. The "uniform abstraction" is to specify security policy in the native terms of the resource being mediated. Files are named as /path/to/some/files/*.html and network resources are named in terms of ports and network addresses reminiscent of firewall rules.

In contrast, SELinux *does* apply the labeled model to everything. That has the strength that you are dealing with the same abstraction all the time, and the weakness that the mapping from the label abstraction to the stuff that admins and users have to actually deal with is arcane.

- forcing policy to be written in terms of individual objects and
filesystem layout rather than security properties.
Name-based access control makes the overt assumption that the name of an object corresponds to its security properties. If your data layout does *not* make such an assumption, then you have some very strange data layout putting highly sensitive objects next to non-sensitive objects.

Note also that the SELinux restorecon mechanism also makes the assumption that path names correspond to security properties: in fact, that is precisely its function, to take a path name and use it to apply a security property (a label). Naturally I have no objection to inferring a security property from the path name :) I just object to the racy way that restorecon does it, combined with the complaint that AppArmor is wrong for doing exactly the same thing in a different way.

Crispin

--
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin
The Olympic Games: Symbolizing oppression and corruption for over a
hundred years

--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux