Thanks for your comments Casey and Kyle.
Just to clarify what I meant:
The following would be used in conjunction with a pathname based
confinement to try to provide some assurances about what a path refers to.
"/etc/shadow" is a name to a sensitive resource. There is no guarantee
that there are not other ways to access this resource. For example a
link "/etc/shadowlink" or a rename to "/etc/shadownewname"
Pathname based security has various advantages (such as the ability to
have more readable and centralised policies by describing resources in
terms of their pathnames) but the above is clearly a problem (if
confidentiality or integrity of a specific resource is important).
Could we find a way to make paths a more reliable mechanism by labeling
the file data with a simple description of names it is allowed to be
accessed with?
If we want "/etc/shadow" to be the only way to access the shadow file we
could label the data with "/etc/shadow". Any attempts to access this
data using a renamed file or link would be denied (attempts to link or
rename could also be denied).
We could label a document with "/home/me/documents/*". Then the document
could be linked or renamed within that specified directory.
Obvious problems with this solution:
* it seems hard to determine what the label should be set to (setting it
to "*" would be tempting and completely negate the whole thing, while
setting it to the current filename would often be too restrictive).
* when files are created these labels need to be created, and they may
need to be changed.
* if this type of solution requires significant additional management
(as it seems to) it is probably not a suitable addition to a pathname
based confinement mechanism.
* A program creating a new file and copying the contents of the file is
outside of the scope of this solution.
* Stoping a path from pointing to arbitrary data is also outside the
scope of this solution (for example "/etc/shadow" could be replaced with
another file).
--
Could a name based policy include the pathname as well as an inode
number or some (more secure) identifying attribute (which could be
calculated based on the supplied pathname)? A one-way-hash would
identify but could not be used for each file a program accesses as they
can change...
--
Anyway just sharing some thoughts as the experimental LSM I am
developing for my research (the details of which will make its way here
eventually) will use pathnames (despite the discussed limitations).
Regards,
Z. Cliffe Schreuders
--
>> Would it make sense to label the data (resource) with a list of
paths (names) that can be used to access it?
>> Therefore the data would be protected against being accessed via
alternative arbitrary names. This may be a simple label to maintain and
(possibly to) enforce, allowing >> path based confinement to protect a
resource. This may allow for the benefits of pathname based confinement
while avoiding some of its problems.
>> Obviously this would not protect against a pathname pointing to
arbitrary data…
>> Just a thought.
>> Z. Cliffe Schreuders.
-
To unsubscribe from this list: send the line "unsubscribe
linux-security-module" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
