Current summary:
We can't use negative numbers. Currently type uid_t is 16 bits. All values
are 'legal' at both the user and kernel level (UID==65535 is legal). UID==0 is not
special in regards to auditing.
As an aside, to address brandon's comment about 'root' logins not being
in a 'secure' system. Neither the CA or LS Protection Profiles (updated C2 and B1)
require or specify this behavior. For example, IRIX 4.0 is on the evaluated systems list
(@ http://www.radium.ncsc.mil/tpep/epl/index.html) at B1 security. It did have 'root'
login access. That system had no CAPabilities nor ACLs, only MAC and auditing.
Based on the first paragraph above, it would seem my original proposal is
still the one that would meet the needed criteria. Some people have mentioned
the 'session id' as already existing and to use that. I find no mention of a session
ID in the process task structure (where the information needs to be, since auditing
is done on a per-process basis). To recap the original proposal:
1) adding a variable "luid" to the uid_t line in the task struct
2) adding two system calls - 1 to 'set' and one to 'get' the value.
3) adding CAP_SET_LUID that allows setting setting the luid.
This proposal would affect no user applications in current systems. It
would be tamperproof on current systems by anyone not possessing CAP_SET_LUID.
More comments?
Thanks,
-linda
-- Linda A Walsh | Trust Technology, Core Linux, SGI law@sgi.com | Voice: (650) 933-5338- 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/
This archive was generated by hypermail 2b29 : Sat Apr 15 2000 - 21:00:26 EST