On 02/05/2013 11:19 AM, Stephen Smalley wrote:
On 02/05/2013 03:44 AM, Mohan Mangal wrote:
Hello,
I am new to Selinux and Seandrod.
While going through the documents of SeAndroid,
Permissions are inherited from file to Directory, Socket File, etc..
But how permissions like 'link' 'unlink' 'append' shall be interpreted
in case of directory.
And what is the significance of 'write' permission in directory when
there is already 'add_name', 'remove_name' permissions defined for
directory.
why 'reparent' permission is not there for a file?
Not all of the common permissions are necessarily meaningful for all
classes that inherit them. link, unlink, and append don't really mean
anything for directory. write is checked on directory because SELinux
mirrors the existing Linux checks in addition to adding its own
finer-grained checks, so when Linux checks write access, so does
SELinux. So to add an entry you need write + add_name, while to unlink
an entry you need write + remove_name. reparent is specific to
directory because it has to do with rewriting the directory's .. entry,
thereby changing the directory's state (unlike the case of a file).
Some resources:
The original tech report that described the classes, the permissions,
and what permissions are checked for each system call (the control
requirements tables).
http://www.nsa.gov/research/_files/selinux/papers/slinux-abs.shtml
The technical report describing the port to LSM and associated changes,
http://www.nsa.gov/research/_files/selinux/papers/module-abs.shtml
A community wiki page that tries to document the classes and permissions,
http://www.selinuxproject.org/page/ObjectClassesPerms
The latter is more likely to be up-to-date, but the technical reports
have the following benefits:
- they often describe the rationale for non-obvious permissions,
- they describe the source/subject and target/object of each permission
check,
- they map system calls (original) or hooks (LSM) to sets of permission
checks.
So I think it is still useful to refer to the tech reports as well.
--
This message was distributed to subscribers of the seandroid-list mailing list.
If you no longer wish to subscribe, send mail to [email protected] with
the words "unsubscribe seandroid-list" without quotes as the message.
