Re: Default local auth policy
On Mar 24, 09 02:10:19 +1100, Daniel Stone wrote: > On Fri, Mar 20, 2009 at 04:36:22PM -0700, Eric Anholt wrote: > > On Tue, 2009-03-17 at 14:06 -0400, Adam Jackson wrote: > > > On Mon, 2009-03-16 at 12:52 -0700, Eric Anholt wrote: > > > > On Fri, 2009-03-13 at 13:46 -0400, Adam Jackson wrote: > > > > > Normally I'd just change the default here, but I think this might be a > > > > > significant enough difference in behaviour that you should have to ask > > > > > for it. So. New -localuser option? Change the default? Bad idea, > > > > > give up, take up farming? > > > > > > > > It sounds sensible, the only thing I'm concerned about is whether with > > > > this new default I could sudo and still get success. > > > > > > It's not particularly well specified, at least for > > > getsockopt(SO_PEERCRED). The Linux implementation appears to give you > > > the effective UID, not real, so suid apps would fail. I'm not sure what > > > the other OS's implement offhand. > > > > And sudo would fail as well? That's extremely uncool. Unless the plan > > is to add +si:localuser:0 as well. > > Yeah, good point. sudo mangles both real and effective gid, so we don't > really have a useful way to tell, so I guess you could just allow root > per default. Sounds reasonable, in principle. However, citing from the manual: "If your system supports this method and you use it, be warned that some programs that proxy connections and are setuid or setgid may get authenticated as the uid or gid of the proxy process. For instance, some versions of ssh will be authenticated as the user root, no matter what user is running the ssh client, so on systems with such software, adding access for localuser:root may allow wider access than intended to the X display." To me this reads as if we MUSTN'T add root as an allowed user, because that MIGHT add a serious security leak. This specifically includes a looged in user 'root', which means that the default wouldn't work in this case :-((( Matthias -- Matthias Hopf ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: Default local auth policy
Hi, On Fri, Mar 20, 2009 at 04:36:22PM -0700, Eric Anholt wrote: > On Tue, 2009-03-17 at 14:06 -0400, Adam Jackson wrote: > > On Mon, 2009-03-16 at 12:52 -0700, Eric Anholt wrote: > > > On Fri, 2009-03-13 at 13:46 -0400, Adam Jackson wrote: > > > > Normally I'd just change the default here, but I think this might be a > > > > significant enough difference in behaviour that you should have to ask > > > > for it. So. New -localuser option? Change the default? Bad idea, > > > > give up, take up farming? > > > > > > It sounds sensible, the only thing I'm concerned about is whether with > > > this new default I could sudo and still get success. > > > > It's not particularly well specified, at least for > > getsockopt(SO_PEERCRED). The Linux implementation appears to give you > > the effective UID, not real, so suid apps would fail. I'm not sure what > > the other OS's implement offhand. > > And sudo would fail as well? That's extremely uncool. Unless the plan > is to add +si:localuser:0 as well. Yeah, good point. sudo mangles both real and effective gid, so we don't really have a useful way to tell, so I guess you could just allow root per default. Note that this still breaks when using sudo -H, which is arguably a very sensible idea in the first place, unless you manually set $XAUTHORITY, and it's not a regression from su -. But blaming the sudo developers for this breaking seems a little pedantic. Cheers, Daniel signature.asc Description: Digital signature ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: Default local auth policy
On Tue, 2009-03-17 at 14:06 -0400, Adam Jackson wrote: > On Mon, 2009-03-16 at 12:52 -0700, Eric Anholt wrote: > > On Fri, 2009-03-13 at 13:46 -0400, Adam Jackson wrote: > > > Currently, if you start X without -ac and without -auth, the default > > > connection policy is to allow connections from localhost. In > > > particular, this means on every IPv[46] address, and any local > > > transports including unix sockets. > > > > > > I'd like to see a mode where the default policy is effectively > > > +si:localuser:`id -un`, which would allow connections only from the uid > > > that started the server. This is effectively the policy everyone's > > > trying to implement with xauth cookies, but cookies have to get stored > > > on disk somewhere which sucks for NFS and r/o images, etc. For the gdm > > > case, the display manager would add the real user to the access list > > > once they've been authed, and then remove itself and start the session > > > as the user. > > > > > > Normally I'd just change the default here, but I think this might be a > > > significant enough difference in behaviour that you should have to ask > > > for it. So. New -localuser option? Change the default? Bad idea, > > > give up, take up farming? > > > > It sounds sensible, the only thing I'm concerned about is whether with > > this new default I could sudo and still get success. > > It's not particularly well specified, at least for > getsockopt(SO_PEERCRED). The Linux implementation appears to give you > the effective UID, not real, so suid apps would fail. I'm not sure what > the other OS's implement offhand. And sudo would fail as well? That's extremely uncool. Unless the plan is to add +si:localuser:0 as well. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: Default local auth policy
On Mon, 2009-03-16 at 12:52 -0700, Eric Anholt wrote: > On Fri, 2009-03-13 at 13:46 -0400, Adam Jackson wrote: > > Currently, if you start X without -ac and without -auth, the default > > connection policy is to allow connections from localhost. In > > particular, this means on every IPv[46] address, and any local > > transports including unix sockets. > > > > I'd like to see a mode where the default policy is effectively > > +si:localuser:`id -un`, which would allow connections only from the uid > > that started the server. This is effectively the policy everyone's > > trying to implement with xauth cookies, but cookies have to get stored > > on disk somewhere which sucks for NFS and r/o images, etc. For the gdm > > case, the display manager would add the real user to the access list > > once they've been authed, and then remove itself and start the session > > as the user. > > > > Normally I'd just change the default here, but I think this might be a > > significant enough difference in behaviour that you should have to ask > > for it. So. New -localuser option? Change the default? Bad idea, > > give up, take up farming? > > It sounds sensible, the only thing I'm concerned about is whether with > this new default I could sudo and still get success. It's not particularly well specified, at least for getsockopt(SO_PEERCRED). The Linux implementation appears to give you the effective UID, not real, so suid apps would fail. I'm not sure what the other OS's implement offhand. - ajax signature.asc Description: This is a digitally signed message part ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: Default local auth policy
On Fri, 2009-03-13 at 13:46 -0400, Adam Jackson wrote: > Currently, if you start X without -ac and without -auth, the default > connection policy is to allow connections from localhost. In > particular, this means on every IPv[46] address, and any local > transports including unix sockets. > > I'd like to see a mode where the default policy is effectively > +si:localuser:`id -un`, which would allow connections only from the uid > that started the server. This is effectively the policy everyone's > trying to implement with xauth cookies, but cookies have to get stored > on disk somewhere which sucks for NFS and r/o images, etc. For the gdm > case, the display manager would add the real user to the access list > once they've been authed, and then remove itself and start the session > as the user. > > Normally I'd just change the default here, but I think this might be a > significant enough difference in behaviour that you should have to ask > for it. So. New -localuser option? Change the default? Bad idea, > give up, take up farming? It sounds sensible, the only thing I'm concerned about is whether with this new default I could sudo and still get success. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: Default local auth policy
> "Adam" == Adam Jackson writes: >> While I disagree that storing cookies in $HOME ‘sucks for NFS’, Adam> I should have clarified. It sucks because NFS is unencrypted and Adam> storing your auth cookies there means the whole wire gets to read them. Adam> If you trust everyone on your local network, great. Ah, OK. I was presuming a secure config. (Or, perhaps, had a fit of nostalgia. :) >> Which leaves the interesting question of what should happen if -auth >> is not specified, but -ac is? Adam> -ac means "disable access control". I must've been just barely awake. While reminding myself of -ac's purpose, I read "disables host-based access control mechanisms." and must've only thought about the host-based part >> Not to mention whether -nolisten tcp also should be the default? >> Or perhaps the default only w/o -ac and -auth? Adam> In the absence of a -listen, that would be unpleasant. Not that Adam> you're necessarily wrong. If the point is to make it easier for the currently typical use case of a single box acting as both server and host-for-the-clients, where unix- domain sockets are the norm, tcp sockets may be unnecessary. In any case, just in case I was ambiguous, +1 to the original idea. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: Default local auth policy
On Sat, 2009-03-14 at 13:50 -0400, James Cloos wrote: > > "Adam" == Adam Jackson writes: > > Adam> Currently, if you start X without -ac and without -auth, > Adam> the default connection policy is to allow connections from > Adam> localhost. ... > > Adam> I'd like to see a mode where the default policy is effectively > Adam> +si:localuser:`id -un`, which would allow connections only from > Adam> the uid that started the server. > > Adam> cookies have to get stored on disk somewhere which sucks for NFS ... > > While I disagree that storing cookies in $HOME ‘sucks for NFS’, I should have clarified. It sucks because NFS is unencrypted and storing your auth cookies there means the whole wire gets to read them. If you trust everyone on your local network, great. > Which leaves the interesting question of what should happen if -auth > is not specified, but -ac is? -ac means "disable access control". > Not to mention whether -nolisten tcp also should be the default? > Or perhaps the default only w/o -ac and -auth? In the absence of a -listen, that would be unpleasant. Not that you're necessarily wrong. - ajax signature.asc Description: This is a digitally signed message part ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: Default local auth policy
On Fri, Mar 13, 2009 at 01:46:06PM -0400, Adam Jackson wrote: > Currently, if you start X without -ac and without -auth, the default > connection policy is to allow connections from localhost. In > particular, this means on every IPv[46] address, and any local > transports including unix sockets. > > I'd like to see a mode where the default policy is effectively > +si:localuser:`id -un`, which would allow connections only from the uid > that started the server. This is effectively the policy everyone's > trying to implement with xauth cookies, but cookies have to get stored > on disk somewhere which sucks for NFS and r/o images, etc. For the gdm > case, the display manager would add the real user to the access list > once they've been authed, and then remove itself and start the session > as the user. > > Normally I'd just change the default here, but I think this might be a > significant enough difference in behaviour that you should have to ask > for it. So. New -localuser option? Change the default? Bad idea, > give up, take up farming? Change the default, seriously. Cheers, Daniel signature.asc Description: Digital signature ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: Default local auth policy
> "Adam" == Adam Jackson writes: Adam> Currently, if you start X without -ac and without -auth, Adam> the default connection policy is to allow connections from Adam> localhost. ... Adam> I'd like to see a mode where the default policy is effectively Adam> +si:localuser:`id -un`, which would allow connections only from Adam> the uid that started the server. Adam> cookies have to get stored on disk somewhere which sucks for NFS ... While I disagree that storing cookies in $HOME ‘sucks for NFS’, I very much agree that a server started w/o -ac and -auth should do exactly what Adam proposes: allow connections, by default, only from the starting UID and only from localhost. When -auth is specified, it should work as it currently does. Which leaves the interesting question of what should happen if -auth is not specified, but -ac is? Not to mention whether -nolisten tcp also should be the default? Or perhaps the default only w/o -ac and -auth? -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
