Messages in this thread | | | From | Bear Giles <> | Subject | Re: Ext3 filesystem info? | Date | Sat, 18 Sep 1999 17:30:17 -0600 (MDT) |
| |
> On Sat, 18 Sep 1999, Michael Bacarella wrote: > > What I meant by ACL was the way NTFS handles it (and afaik solaris has it > now) : You can assign much more fine grained access to the file. Instead > of just one group and one owner, you can give any user or group of users > any set of permissions.
ACLs can (and should?) provide additional restrictions. Each entry should specify
user and/or group
permissions RWX at a minimum. On some systems you can specify "append-only", "creation" (sys_link and sys_symlink), "deletion" (sys_unlink and sys_truncate) and "modify attributes" (sys_chown, sys_chgrp, sys_chacl). EXT2FS already supports two of these flags (au). A trusted file system should also always perform secure deletions (s).
nature of access Limit access to specific times of the day or days of the week. Limit access to specific ports (e.g., only console/virtual terminals) On some systems you can also bracket the access with "valid" and "expiry" dates. This allows you to specify that the file can only be accessed between 8AM and 5 PM on weekdays, and from 01 November to 15 December 1999.
ACLs are a "discretionary access control," the specs also appear to require a similar "non-discretionary access control" which applies to everyone and which *can't* be set by the owner of the file. The concept seems similar to the mount options "readonly" and "noexec" taken down to the level of files.
If you think this is more than NTFS supports, I agree. I don't know if it got a waiver or if the ISO document is more restrictive.
This sounds like a lot of information, but I think it depends on your perspective. If you're trying to shove it all into an existing inode structure you'll have problems. If you're willing to use a single disk block, possibly one shared with other files (by this I mean a full disk block which acts as an exemplar, not each file having exclusive access to part of a disk block) then you can pack in a *lot* of security information.
BTW, other information that could be (or needs to be) included is:
- auditing flags (e.g., record all access, of any kind, of /etc/shadow) - sensitivity level ("B1" classification, it's a bitmap indicating unclassified/sensitive/confidential/secret/top secret & compartmentalization) - encryption information
There are at least two types of encryption information. One is the actual encryption key, itself encrypted by a super-block level encryption key specified during "mount." Another type of encryption info is something like the cryptographic hash of the unencrypted first block of the file. The user must pass the password, via an IOCTL, which decrypts the first block so it produces the known hash value, before the user can use read() and write().
(Ref: Sept. _SysAdmin_ magazine, and the recently adopted IS 15408 discussed in the editoral at the beginning of the magazine).
Bear Giles bgiles@coyotesong.com
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |