SELinux is a security architecture providing type-enforcement and
RBAC on Linux. It is implemented using the Linux Security Modules
hooks which is intended to become a standard part of the kernel
distribution (by my understanding this won't happen until 2.5 / 2.6)
JFS seems to work ok in this if you make the appropriate additon
to the SELinux 'hooks.c' file, identifying jfs as a filesystem
with persistent inodes. There will probably be security modules which
do not track security data by inode-mapping, I'm not concerned about
those just now, however.
For a filesystem to 'play nice' in this environment I believe there
are 2 basic requirements (there ar probably others I've not thought
of yet :-().
1. Inode:file mapping needs to be unique and persistent.
2. Generally writes to the filesystem need to be routed
through the LSM code. I believe that this effectively
means there should be no *security-meaningful* calls
which do not use the VFS interface.
So, questions for the JFS developers:
Is inode-file mapping persistent? Is it possible for mapping to
be changed during log restore or other operations.
Are there any new calls or interfaces which could circumvent the
standard VFS interface and allow security-significant changes to
be made to a filesystem.
I believe SELinux provides facility to limit fsck.jfs and its
helpers, or logdump etc to appropriate security contexts and
access to the raw devices. As above this would depend on the
code doing all /dev/* access thru the kernel I expect this is
the case.
Parenthetically, In looking at jfsutils I note that there's no
'dump / restore' facility? Are there no inode-back utilitys?
thanks for any thoughts on this
forrest
_______________________________________________
Jfs-discussion mailing list
[EMAIL PROTECTED]
http://www-124.ibm.com/developerworks/oss/mailman/listinfo/jfs-discussion
