On Mon, Feb 12, 2007 at 12:54:14PM -0500, David Zeuthen wrote: > secure (the cookies are dispensed by ConsoleKit and thus random, e.g. > you can't guess the cookie that other users have); just don't change > XDG_SESSION_COOKIE. That ought to be ok if they are truely random, sufficiently long and not subject to a usable timing attack yes. > Which is not good enough; we need a model where we can make a > distinction between the actual sessions so we can deny service to > sessions depending on whether they are active / local or whatnot. Do you > agree this is an important goal? What guarantees we make, and more I don't understand why you require security for this. I can see why it is useful in an advisory manner (typing reboot in the wrong window failing because it is remote even though I have a local session on the tagret box may save a few backsides by avoiding errors) > model where this is not possible I'd be happy to hear about it. Thinking > about it, I agree it wouldn't make sense; you're already logged in > locally so you could just have a VNC server or equivalent running and > you could use this to use the privileges exposed by the local session. > So I'm not sure what the fuss is about? I'm not sure what you are trying to do that doesn't just work already. If your model is that there are some set of users who have processes on the system, and that 1 or more of those users are members of a subset who have 'special powers' because at that moment they posess a session which is 'active', 'local', etc then you need to ensure that the privileged agent which manages the creation of sessions/switching of active session and the privileged agents which implement the special powers share a common dynamic list/database indicating which uids are currently entitled to exercise special powers. Sessions don't seem relevant here except that ownership of one in certain states gives you certain power at that time. We seem to be talking (and no I wouldnt do the implementation in sh..) gdm login touch /var/sessions/auth-$uid gdm logout rm /var/sessions/auth-$uid reboot if [ -e /var/sessions/auth-$uid] ; then Our security is by uid, our file and memory level security is by uid so that is the security you get for most things. (Passed file handles are a bit more interesting ways of passing rights) Having a non security based notion of 'the active session' not 'the uid of the active session' makes sense but that can be very relaxed - just pass XDG_SESSION_COOKIE around explicitly. I can extract the key from one app to another of the same uid is easy but a deliberate act by something in the same security domain. In other words security: uid in the dynamic list of folk entitled to super-power X accident avoidance: explicitply passed XDG_SESSION_COOKIE with a request. Once you want to distribute that auth then it seems to be it really does turn into a hard problem, and that maps directly to kerberos. Alan -- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers -- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
