> I agree, the current capability model has to be supported is a given. A > few of us here have a very rough cut that moves the capability model out > into a loadable module, with a "generic" security interface. Give us a > few days of fleshing it out some more and we'll post it to the list for > comments. The problem is that the current model is a hack (I share a lot of the blame for it, but it has evolved a little out of control since). It has some conceptual flaws and some ill-defined features. Its 'legacy' support, for example, is less than ideal. That said, a loadable module implies you've booted before it gets installed, which implies that there are security relevant decisions and an execution environment that has already violated the 'POSIX' capability model. > A question, does the kernel's current capability code meet the POSIX > model? I was under the impression that POSIX never released a final > recommendation for capabilities. Any pointers would be appreciated. The model in the kernel is about 1/2 of the POSIX model (no filesystem support) with a small dose of 'extra features' to make it usable. The full model (as captured in the 'last' POSIX.1e draft [*]) is supported with this 'kernel patch' (for 2.2.18): http://www.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.2-fcap/ The full POSIX.1e draft spec is available on-line here: http://www.guug.de/~winni/posix.1e/download.html it includes more sections than just 'Capabilies', namely: ACLs; MACs; ILs; and Audit APIs. One of the things that the 'full' model requires, that is not present in regular kernels, is a method to store security attributes in association with inodes. For this, the above patch makes use of 'extended attributes' (another kernel patch!): http://acl.bestbits.at/download.html which is being developed in conjunction with the POSIX.1e ACL model (another patch!) for Linux (and I understand this ACL implementation is actually 'assumed' by recent Samba releases...). Hope all this is useful background info. Cheers Andrew [*] the reason that this didn't actually make it to being a POSIX standard is an interesting tour in the economic realities of trying to get UNIX vendors to agree on a security infrastructure - in the absence of a market demand for a standard (the US gouvernment decreed a standard - the Orange Book - and then mostly waived requirements to adhere to it).
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:15:21 PDT