Ok, I've tried to summarize my desired security policy below.
I'd suggest allowing behavior "A" or "B" as a compile time option.
I'd suggest a system call to set the system-bounding set. Once lowered
it can't be raised (would need to reboot).
Capability inheritance proposal (conforms to POSIX1003.1eDS16, not DS17
was watered down to try to swing 2 more votes -- as a result,
I feel it was made less secure.
Notation:
B=system-wide bounding set (applied at runlevel > single)
Capsets are expressed as a triplet PIE :Permitted, Effective, Inheritable)
Initial value for root=(B,B,B)
Initial value for user=(0,B,0)
Default for normal files=(0,B,B)
Default for SUID-root (when not SECURE_NOROOT) files = either “A” (b,0,b)
Or less-secure, but 100% compatible with today’s paradigm “B” (b,b,b)
Using the new exec rule:
1) pI' = pI & fI
2) pP' = fp | (pI' & pP)
3) pE' = fE & pP'
Normal files, root:
1) pI'=B & B; 2) pP'= 0 | (B & B); 3) pE'=B & B
new PIE=(all,all,all) – no change of security state
Normal files: non-root:
1) pI'=B | B; 2) pP'= 0 | (B & 0); 3) pE'= all & 0
new PIE=(0,B,0) – no change of security state
For suid-root, root:
1) pI'=B & B; 2) pP'= | (B & B); 3) pE'=B & B
new PIE=(B,B,B) – no change of security state (expected)
The differences in file defaults (either “A” or “B” above) come here:
A) Suid-root, non-root users:
1) pI'=B & 0; 2) pP'= B | (0 & 0); 3) pE'= B & B
new PIE=(B,0,B) – New process has desired
system-bounded set and no exec’ed processes get
privileges passed on. This one would provide an environment
that would work w/most apps and provides some protection
against creating a straight path to a privileged shell.
B) suid-root, non-root users:
1) pI'=B & B; 2) pP'= B | (B & 0); 3) pE'= B & B
PIE’=(B,B,B) – new process has system-bounded set and complete
Compatibility w/today’s applications that assume capabilities
Are passed on to called programs.
Notes:
If/when we get file capabilities and/or default caps on mounts -
"Trusted" files could have (0,B,B), and "untrusted file systems" (say
"user-writable" ones) could have a default set of (0,0,0). Voila!
Instant basic integrity model -- all done w/o filesystem changes --
it's an in-memory, run-time-only superblock option (ultimately to
be set as mount-options).
setcap system call allows changing of capset on a target process(es)
assume PIE passed in is aPIE (arg). "t"=target process.
assuming proper privilege:
Using <=.>=, for subset notation "is subset", "is superset":
if aP <= (pP & pI) && aE <= (ap & pP & pI) {
tI' = aI;
tP' = aP & pP & pI
tE' = aE & tP'
} else return -EPERM;
Notes:
For tP' calculation I'm and'ing with the "Inheritable" set so that
any Capabilities not *explicitly* set to be Inheritable are not passed
on. This means a process would first have to raise it's Inheritable set to
allow passing of capabilities.
-- 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 : Wed May 31 2000 - 21:00:26 EST