Next privilege escalation policy draft
ajax at redhat.com
Thu Feb 4 20:14:19 UTC 2010
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.
Thank you for taking this on. Apologies for not looking this over
sooner, I've been away from email for the last two weeks.
- "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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100204/2eb316da/attachment.bin
More information about the devel