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/