On Mon, 2010-02-01 at 15:47 -0800, Adam Williamson wrote: > Hi again, folks. Here is another draft of the privilege escalation > policy. This is the sixth draft (second to this list). Changes: one of > Kevin Kofler's queries alerted me to the fact that somehow all the > changes between draft 1 and draft 2 were lost from drafts 3 onwards, > d'oh :) They are restored, which addresses some points people raised > here that were previously raised and addressed on test list. I also > tried to clarify some more that the planned system whereby there'll be > an 'administrative users' group that the first account gets added to > automatically and to which other users can be added manually is OK, and > clarified the point KK misunderstood about what constitutes a 'policy > escalation mechanism'. > > again, comments are welcome! This is probably going to FESco next week, > not tomorrow, apparently they have a heavy schedule tomorrow. > > https://fedoraproject.org/wiki/User:Adamwill/Draft_Fedora_privilege_escalation_policy Thank you for taking this on. Apologies for not looking this over sooner, I've been away from email for the last two weeks. Some nitpicking: - "Read or write directly to or from system memory" is, technically, something every process does. "Device or kernel memory" might be closer to the spirit of the law? - Declaring "Read from system logs containing any information about user activities" to be a privileged action, means that who(1) and last(1) break, since utmp and wtmp are typically - intentionally - world readable. /var/log/ConsoleKit/history similarly. I think this entire rule is mostly subsumed under the "directly access or modify a file they would usually be denied rights to" clause, though we'd probably also want to define what kinds of log information are sensitive and what aren't in that case, and enforce world-readability to match. - ajax
Attachment:
signature.asc
Description: This is a digitally signed message part
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
