Re: [vox-tech] xhost+: Why you should NEVER DO THAT
On Friday 18 March 2005 02:18, Karsten M. Self wrote: Mark Kim apparently insists on dispersing bad advice regarding use of xhost + to allow remote X11 access. I agree that it's a bad advice. When user needs that advice, he likely doesn't know intricacies of X enough to know which situations are acceptable to use xhost + in, and and which ones are not. User will probably end up thinking x access problems? == xhot +!. And this applies to other technical answers too. While it might be easier to say oh just do it in the insecure way, you are safe in your circumstances, user will likely remember solution, and possibly offer it as advice to someone else without full understanding of security implications. Or perhaps someone else searching archives and thinking his problem might be similar. He tries xhost +, and voila, it worked. Except he was sitting in a university lab with open xports. Boo. Again, both of this scenarios are very undesirable. So please avoid advice that can very easily be harmful to people. Remember that there are archives that show up on google, and different people are likely to have slightly different circumstance, and not everyone is fully aware of security implications. (And even if next email explains alternatives and implications, user who has a problem is not going to bother reading it all, 95% of the time. Trust me) -- Dmitriy - LUGOD VP ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] xhost+: Why you should NEVER DO THAT
On Mon, Mar 21, 2005 at 11:33:39AM -0800, Dmitriy wrote: On Friday 18 March 2005 02:18, Karsten M. Self wrote: Mark Kim apparently insists on dispersing bad advice regarding use of xhost + to allow remote X11 access. I agree that it's a bad advice. As do I. On the other hand, this whole thread has blossomed into a very full discussion, with lots of references, on _why_ xhost + is bad, and comparing/contrasting other connection schemes. In one sense, Karsten and others have/might argue: People will google and find xhost + is your answer and get BAD INFORMATION! NOT GOOD! But on the other hand, there's a whole /THREAD/ of information on _why_ it's bad, so that people who might think xhost + is as good as SSH will see why it is NOT. (OTOH, if the thread simply said use SSH, their incorrect assumption won't be brought to light.) When user needs that advice, he likely doesn't know intricacies of X enough to know which situations are acceptable to use xhost + in, and and which ones are not. This is a good consideration to make when answering questions here, and elsewhere. snip Again, both of this scenarios are very undesirable. So please avoid advice that can very easily be harmful to people. Remember that there are archives that show up on google, and different people are likely to have slightly different circumstance, and not everyone is fully aware of security implications. (And even if next email explains alternatives and implications, user who has a problem is not going to bother reading it all, 95% of the time. Trust me) Oh, I guess maybe it's just me. I make full use of Next in thread and References links in mail archives, personally. ;) -bill! ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] xhost+: Why you should NEVER DO THAT
I really wanted to get off of this topic but I will defend myself. Did anyone read my original post?: [snip] $xhost + *but* this will work only if your local computer is connected directly to the Internet. The better way is to use ssh with the -X option to connect to the remote computer in the first place. Not only does ssh setup the X forwarding for you automatically (not need to do export blah blah or xhost blah blah or be concerned about not being connected directly to the Internet), but your connection will be secure. ^^^ [snip] The reason I mentioned xhost is because that's the direction John was headed in his original attempted solution. Then I mentioned ssh because it is what he *should* use. Perhaps I should have emphasized security more, but I resent the notion that I gave a bad advice. Since we discussed this topic to death I'd like to ask that this thread be stopped at this point. -Mark On Mon, 21 Mar 2005, Dmitriy wrote: On Friday 18 March 2005 02:18, Karsten M. Self wrote: Mark Kim apparently insists on dispersing bad advice regarding use of xhost + to allow remote X11 access. I agree that it's a bad advice. When user needs that advice, he likely doesn't know intricacies of X enough to know which situations are acceptable to use xhost + in, and and which ones are not. User will probably end up thinking x access problems? == xhot +!. And this applies to other technical answers too. While it might be easier to say oh just do it in the insecure way, you are safe in your circumstances, user will likely remember solution, and possibly offer it as advice to someone else without full understanding of security implications. Or perhaps someone else searching archives and thinking his problem might be similar. He tries xhost +, and voila, it worked. Except he was sitting in a university lab with open xports. Boo. Again, both of this scenarios are very undesirable. So please avoid advice that can very easily be harmful to people. Remember that there are archives that show up on google, and different people are likely to have slightly different circumstance, and not everyone is fully aware of security implications. (And even if next email explains alternatives and implications, user who has a problem is not going to bother reading it all, 95% of the time. Trust me) -- Dmitriy - LUGOD VP ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech -- Mark K. Kim AIM: markus kimius Homepage: http://www.cbreak.org/ Xanga: http://www.xanga.com/vindaci Friendster: http://www.friendster.com/user.php?uid=13046 PGP key fingerprint: 7324 BACA 53AD E504 A76E 5167 6822 94F0 F298 5DCE PGP key available on the homepage ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] xhost+: Why you should NEVER DO THAT
On Monday 21 March 2005 12:48, Mark K. Kim wrote: I really wanted to get off of this topic but I will defend myself. Did anyone read my original post?: This wasn't as much a response to your specific post (I didn't really mention much specifics as to what you said, just used trivialized xhost example), as much as general advice to posters, and something to keep in mind. If you took it very personally Mark, I apologize. I was trying to address more general issue pertaining to vox-tech advice. I had no interest in participating in resulting almost flame war. -- Dmitriy ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] xhost+: Why you should NEVER DO THAT
On Friday 18 March 2005 19:37, Karsten M. Self wrote: on Fri, Mar 18, 2005 at 06:08:04PM -0800, Richard Harke ([EMAIL PROTECTED]) wrote: On Friday 18 March 2005 16:12, Karsten M. Self wrote: The history of secure applications development is largely divided into two groups: 1. Those who anticipate hostile environments, design for scenarios in which no two components trust one another, and correctly implement failsafe, trust, integrity, and encryption procedures. 2. Those who've been the source of multiple compromises. Paranoia pays off here. Safe practices pay off. Even those who _are_ paranoid and cautious suffer breakins (the good ones will let you know that this has happened). The truely frightening are those who deny the problem exists _and_ fail to recongize a compromise when they see it. When I first installed firefox it refused to run. You don't provide any specifics on the problem or why it refused to run. Nor is there a record of your encountering this problem on the LUGoD lists or in Google (based on your first+last name and keyword 'firefox'). I'm going to presume this was Firefox 0.9.x and your problem is similar to that described here: http://lists.suse.com/archive/suse-kde/2004-Aug/0122.html Specifically quoting a readme file: Because of missing registration features in firefox 0.9.x you have to start firefox as root the first time after installation. If you get a message like -8--snip--8-- Xlib: connection to :0.0 refused by server Xlib: XDM authorization key matches an existing client! -8--snap--8-- you have to disable the X authorization with command 'xhost +' and startup firefox. After the initial startup you can close your X session again by 'xhost -' and you should be able to start firefox from now on without problems. This is in fact the problem I had. I never saw the readme though and never did try to start firefox as root. After xhost + I could start firefox as a user but after I did xhost -, it would not start. This has changed since I did the update. That is, it refused to run. I did xhost + It would run. I did xhost - and it still runs. I still have not run it as root. My first installation was some time after version 1.0 was announced but I didn't check the version at debian. After googling about I found the advice to do xhost +. Best I can tell (I don't have the broken Firefox build on my system, and never encountered it), so this is based on general experience: - The xhost advice is unnecessary. The alternative I've mentioned in this discussion -- running 'sux' or as root setting $DISPLAY and merging the user's ~/.xauthority file -- would be sufficient. 'xhost +' is faster and easier, but remains bad advice. I'm not sure if SuSE ships with 'sux', but tool ommissions in other areas on a recent SuSE 9.1 build don't impress me. - This is a fix which is local to the system at hand. 'xhost + localhost' would probably also have worked, and would have _not_ dropped all access security to your X display. - On a sanely configured X server, not listening to external TCP traffic, even running 'xhost +' would not open you up to external hosts, due to your server settings. This is where Mark Kim's advice is mind-bogglingly inappropriate: not only is it overtly harmful (in the event of a misconfigured X server), but (in the case of a correctly configured one) it fails to address the problem at hand. Incidentally, if your X server _is_ listening to external TCPIP traffic, and you haven't explicitly configured it to do so yourself, you _should_ write file a bug report. Based on this thread I should have rejected the advice leaving me with two alternatives: 1: download the firefox source and debug it. That's your prerogative, and I'm sure the Firefox team would have appreciated your contribution. 2: apt-get purge firefox (followed by a nasty email to somewhere) While I suspect there's a hint of tongue-in-cheek in your response, that You're right would have been _fully_ appropriate. Firefox shipped with a broken config (as noted in the README fragment quoted in the post referenced above), and supplied a workaround which is dangerous and highly questionable. You are, however, ommitting the several options available to you for running X applications as root which _don't_ involve inviting the world to your desktop: As noted above, I didn't think about running firefox as root. Also, I have my system configured so I startx as a user after I login so I'm not sure how the firefox readme would apply. (I assume most users have X started by root immediately after booting up) 3: 'sux commmand' 4: (su|sudo to root) export DISPLAY=display; xauth
Re: [vox-tech] xhost+: Why you should NEVER DO THAT
Quoting Richard Harke ([EMAIL PROTECTED]): Thanks for the explanations, I have learned a lot. I guess I should have posted the problem here in the first place. It's been a good discussion, in part because it's been wide-ranging. ;- Just so your actual problem doesn't get lost, what I think I would do in your shoes is: 1. (indeed:) $ sudo apt-get --purge remove mozilla-firefox [1] (Terminate that sucka' with extreme prejudice. It'll feel good.) 2. $ sudo apt-get update $ sudo apt-get dist-upgrade 3. $ sudo apt-get install mozilla-firefox That is, I'd guess that someone screwed up very badly, constructing that package -- as Karsten was suggesting -- and that the thing to do is get a newer package. You probably don't need to purge the old one, but ritual exorcisms have their uses. ;- (More seriously, sometimes getting rid of aberrant configuration files _is_ the key.) [1] Yes, you could indeed use aptitude's command-line mode, instead. Force of habit. -- Cheers, Rick MoenFrater Magnus vos spectat. [EMAIL PROTECTED] ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
[vox-tech] xhost+: Why you should NEVER DO THAT
Mark Kim apparently insists on dispersing bad advice regarding use of xhost + to allow remote X11 access. I suspect most of us pride ourselves over the fact that GNU/Linux can be made more secure (and generally is more secure as configured) than legacy MS Windows systems. This doesn't mean you can't blow the whole concept with some really bone-headed actions and advice. xhost + is among the more blatant abuses. It flies in the face of well over a decade of both administrator advice and official warnings. A little bit of history and technology: The X Window System is a _networked_, _multi-platform_, _graphical dsiplay system_. It does _not_ have an inherent security model, though several have been tacked on over the years. These include: - xhost: host-based access control (a/k/a no access control) - MIT-MAGIC-COOKIE-1: (cleartext) token-based control. - SSH X11 tunneling: encrypted, authenticated access control You'll find that most modern X servers put a few additional roadblocks in place, which for the reasons stated previously, I won't mention explicitly, and would appreciate others not either. Research on your own and identify why there are security issues. Short answers: -- Remote X11 Access: Use SSH --- If you want to provide or allow remote access to an X display or client, use SSH with X11 tunelling. Read your client and server documentation for details. Generally: # Allow multiple commandline or X commands ssh -X remotehost commands or # Single command run on a forked SSH session ssh -Xf remotehost command are what you want. Running (local) X applications as root -- The 'sux' (su X -- superuser X) command on some distros provides for this. sux command If this isn't available, a slightly longer alternative is: - Identify your non-root user's X display: echo $DISPLAY - go root: 'sudo bash -l' or 'sudo su -' - set root's display: export DISPLAY=user's display - merge user's xauth file: xauth merge ~user/.xauthority - run command(s) X and network access -- X is a wholly network-transparent protocol. This is useful (users and the applications they run need not be at the same location) and leads to some interesting applications (Xnest), but also results in vulnerabilitys. Specifically: Any user with network access to an X display can present or snoop any arbitrary content from that X display. At its simplest level, this means it's possible to trivially take screenshots of a remote X display. It's also possible to write clients which track and record keystrokes and other actions on the screen. More deviously, a malicious client could present its own content to be displayed, say, to fool a user into entering sensitive information on a misrepresented dispaly -- analagous to the common phishing data divulgance attacks today. A password dialog, for example. The other issue with X is that network data are not encrypted or (barring add-ons) authenticated. On network segments open to snooping (wireless networks, hubbed networks, third-party-controlled segments), all X traffic can be intercepted or subject to other attacks such as man-in-the-middle. With ever increasing network interconnections, security issues on common network clients (particularly Microsoft systems), and the ready availability of bootable network security and spying tools (Trinux, Knoppix, LNX-BBC), trust in any but the smallest and most tightly controlled network segments should be minimal. The Intranet is dead. Remote X Access Controls There are three general control mechanisms available for X sessions: - xhost (don't use) - MIT-MAGIC-COOKIE-1 (provides minimal protection) - SSH tunnelling (strongly recommended) xhost access control The simplest form of control is to restrict access to named hosts. Hosts are added with the command: xhost +hostname ...or removed with: xhost -hostname All hosts can be removed with: xhost - Its counterpart is among the major problems, but it's not the only one. The xhost concept has several major weaknesses: - Any user on a named host is allowed access (Secure RPC allows [EMAIL PROTECTED] specification, this is not in widespread use). - Spoofing the hostname can allow an unauthorized host access. This is possible via numerous name resolution hacks. - The notation 'xhost +' is equivalent to _no_ host restrictions, and allows _any_ host to access the X display to present, intercept, or modify data and/or graphics. xhost is subject to
Re: [vox-tech] xhost+: Why you should NEVER DO THAT
On Fri 18 Mar 05, 2:18 AM, Karsten M. Self kmself@ix.netcom.com said: Mark Kim apparently insists on dispersing bad advice regarding use of xhost + to allow remote X11 access. I suspect most of us pride ourselves over the fact that GNU/Linux can be made more secure (and generally is more secure as configured) than legacy MS Windows systems. This doesn't mean you can't blow the whole concept with some really bone-headed actions and advice. xhost + is among the more blatant abuses. It flies in the face of well over a decade of both administrator advice and official warnings. A little bit of history and technology: The X Window System is a _networked_, _multi-platform_, _graphical dsiplay system_. It does _not_ have an inherent security model, though several have been tacked on over the years. These include: - xhost: host-based access control (a/k/a no access control) - MIT-MAGIC-COOKIE-1: (cleartext) token-based control. - SSH X11 tunneling: encrypted, authenticated access control You'll find that most modern X servers put a few additional roadblocks in place, which for the reasons stated previously, I won't mention explicitly, and would appreciate others not either. Research on your own and identify why there are security issues. Short answers: -- Remote X11 Access: Use SSH --- If you want to provide or allow remote access to an X display or client, use SSH with X11 tunelling. Read your client and server documentation for details. Generally: # Allow multiple commandline or X commands ssh -X remotehost commands or # Single command run on a forked SSH session ssh -Xf remotehost command are what you want. Running (local) X applications as root -- The 'sux' (su X -- superuser X) command on some distros provides for this. sux command If this isn't available, a slightly longer alternative is: - Identify your non-root user's X display: echo $DISPLAY - go root: 'sudo bash -l' or 'sudo su -' - set root's display: export DISPLAY=user's display - merge user's xauth file: xauth merge ~user/.xauthority - run command(s) X and network access -- X is a wholly network-transparent protocol. This is useful (users and the applications they run need not be at the same location) and leads to some interesting applications (Xnest), but also results in vulnerabilitys. Specifically: Any user with network access to an X display can present or snoop any arbitrary content from that X display. At its simplest level, this means it's possible to trivially take screenshots of a remote X display. It's also possible to write clients which track and record keystrokes and other actions on the screen. More deviously, a malicious client could present its own content to be displayed, say, to fool a user into entering sensitive information on a misrepresented dispaly -- analagous to the common phishing data divulgance attacks today. A password dialog, for example. The other issue with X is that network data are not encrypted or (barring add-ons) authenticated. On network segments open to snooping (wireless networks, hubbed networks, third-party-controlled segments), all X traffic can be intercepted or subject to other attacks such as man-in-the-middle. With ever increasing network interconnections, security issues on common network clients (particularly Microsoft systems), and the ready availability of bootable network security and spying tools (Trinux, Knoppix, LNX-BBC), trust in any but the smallest and most tightly controlled network segments should be minimal. The Intranet is dead. Remote X Access Controls There are three general control mechanisms available for X sessions: - xhost (don't use) - MIT-MAGIC-COOKIE-1 (provides minimal protection) - SSH tunnelling (strongly recommended) xhost access control The simplest form of control is to restrict access to named hosts. Hosts are added with the command: xhost +hostname ...or removed with: xhost -hostname All hosts can be removed with: xhost - Its counterpart is among the major problems, but it's not the only one. The xhost concept has several major weaknesses: - Any user on a named host is allowed access (Secure RPC allows [EMAIL PROTECTED] specification, this is not in widespread use). - Spoofing the hostname can allow an unauthorized host access. This is possible via numerous name resolution
Re: [vox-tech] xhost+: Why you should NEVER DO THAT
On Fri, 18 Mar 2005, Peter Jay Salzman wrote: On Fri 18 Mar 05, 2:18 AM, Karsten M. Self kmself@ix.netcom.com said: Mark Kim apparently insists on dispersing bad advice regarding use of xhost + to allow remote X11 access. [detailed argument against this elided] If my firewall blocks tcp/udp ports 6000-6007, can you tell me how my x11 events can be captured by someone other than my lovely wife and cat? My $0.02: a) Good security practices should be a matter of habit... you never know when your outer defenses have been compromised. I know, this is like backing up regularly... most of us don't, but that doesn't change the value of the advice. b) Ssh is recommended over telnet, too... but this recommendation is just shorthand... really, sshd is recommended over telnetd... telnet is still useful for troubleshooting other protocols, but for actually logging into another machine ssh is better in every way, so why risk telnetd? [1] The xhost argument is similar... why get into the habit of leaving your X server open to abuse when better alternatives exist? c) For running programs like ethereal that need both superuser and X, I use sudo locally, since I don't have to use the superuser password. --- [1] Last time I ran telnetd was on an embedded system that was too short on RAM to run sshd... but obviously this device had to remain inside a firewall, so its utility was limited, and such situations should be eradicated wherever possible. I am dismayed that commodity routers keep coming with telnetd as an option, since this is a hole in layered security. --- Jeff NewmillerThe . . Go Live... DCN:[EMAIL PROTECTED]Basics: ##.#. ##.#. Live Go... Live: OO#.. Dead: OO#.. Playing Research Engineer (Solar/BatteriesO.O#. #.O#. with /Software/Embedded Controllers) .OO#. .OO#. rocks...1k --- ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] xhost+: Why you should NEVER DO THAT
Quoting Peter Jay Salzman ([EMAIL PROTECTED]): If my firewall blocks tcp/udp ports 6000-6007, can you tell me how my x11 events can be captured by someone other than my lovely wife and cat? I have little to add to Jeff Newmiller's excellent answer, except that I breathe easier knowing that we don't trust our own home LAN any more than we would the Internet. Among other things, this let us add wireless without any change to the house's security model, because we hadn't placed reliance on perimeter protection, in the first place. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] xhost+: Why you should NEVER DO THAT
On Fri 18 Mar 05, 8:42 AM, Rick Moen [EMAIL PROTECTED] said: Quoting Peter Jay Salzman ([EMAIL PROTECTED]): If my firewall blocks tcp/udp ports 6000-6007, can you tell me how my x11 events can be captured by someone other than my lovely wife and cat? I have little to add to Jeff Newmiller's excellent answer, except that I breathe easier knowing that we don't trust our own home LAN any more than we would the Internet. Among other things, this let us add wireless without any change to the house's security model, because we hadn't placed reliance on perimeter protection, in the first place. True enough. True enough. That said, I never used xhosts + (or whatever it) in my life, but I do remember Redhat Unleashed a long, long time ago (back in the RH 5.1 days) recommended it. I never needed to back then because ssh -X always seemed to work. However, it should be pointed out that once someone gets access to your LAN, even ssh, sshd and gnupg are all suspects. Pete -- Save Star Trek Enterprise from extinction: http://www.saveenterprise.com GPG Fingerprint: B9F1 6CF3 47C4 7CD8 D33E 70A9 A3B9 1945 67EA 951D ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] xhost+: Why you should NEVER DO THAT
Peter Jay Salzman wrote: However, it should be pointed out that once someone gets access to your LAN, even ssh, sshd and gnupg are all suspects. I disagree. Were this the case, then you could not use ssh or sshd over the internet; or gnupg while connected to the internet. There's little difference between them. And in the specific case of using ssh for X port-forwarding on the very same machine, nothing's going over the wire anyway. Now, if someone gets remote access to your /host/, and you don't have reasonable measures in place, that's another matter. If someone gets physical access to your host in any way, of course you can't be sure of anything. But for instance: if I specifically allow someone access to my home LAN--say, a neighbor--and do not know him well enough to be sure that he wouldn't try to sniff passwords or packets, I am still very safe in using ssh, whether on one computer or between two; provided he doesn't have inappropriate access to either host. -Micah ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] xhost+: Why you should NEVER DO THAT
On Fri, Mar 18, 2005 at 02:18:27AM -0800, Karsten M. Self wrote: snip xhost access control snip - Any user on a named host is allowed access (Secure RPC allows [EMAIL PROTECTED] specification, this is not in widespread use). This was troublesome when I was in college. We'd use the cruddy old Mac II systems as X servers (displays) and run applications on the Solaris box hiding in the sysadmin's office. Since we'd all be doing xhost +zippy (the Solaris box in question), the pranksters would often decide to do little while (1) bash scripts that fired xclock up on another user's display. Since these were Macs... and slow ones at that... it often require a reboot just to get the system usable again. Stupid Macs. :^) -bill! ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] xhost+: Why you should NEVER DO THAT
Just anticipating quibbles: While I was at it, I figured: Why not also adopt a model that none of the machines trusts each other, either? This, likewise, proved pretty easy once I got well into the mindset. I still use that model, today: Each of my machines has a security perimeter at the edge of its case, and I place no reliance whatsoever on firewalls for primary protection. 1. It's important to remember that common schemes for encrypting network traffic require that _both endpoints_ be trustworthy. E.g., in the general case, all that careful SSH operation and key management gains you is the ability to avoid needing to trust the network _between_ those endpoints: If the machine at the far end has been subverted, you could be creating a problem at the near end. It's tough to get around that limitation, but can be done for limited-scope applications. E.g., here's a way to do remote backup via a bulk-copying run over SSH transport by a cronjob, using an SSH keypair locked down to only one permitted operation: SSH Public-key Process on http://linuxmafia.com/kb/Security/ Even though the job runs on a not-necessarily-trustworthy remote machine, the keypair is allowed to trigger across the tunnel only one, fairly safe operation on the near end. 2. If an SSH keypair usable for general remote shell access gets compromised because you used it on a compromised remote host (exposing it to loggers on that host), then you definitely now have a problem: Break-in without Remote Exploit on http://linuxmafia.com/kb/Security/ Part of knowing your tools is knowing their design limits. ;- ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] xhost+: Why you should NEVER DO THAT
on Fri, Mar 18, 2005 at 07:54:50AM -0500, Peter Jay Salzman ([EMAIL PROTECTED]) wrote: On Fri 18 Mar 05, 2:18 AM, Karsten M. Self kmself@ix.netcom.com said: Mark Kim apparently insists on dispersing bad advice regarding use of xhost + to allow remote X11 access. Pete: no need to quote 384 lines. If my firewall blocks tcp/udp ports 6000-6007, can you tell me how my x11 events can be captured by someone other than my lovely wife and cat? 1. You can never trust cats. 2. Does your network include wireless access? 3. Is your network radiation shielded? 4. Is all your hard-wired network directly visually inspectable? 5. Are foreign systems allowed on the network? A small home LAN or an airgapped lab / classroom LAN are two of the conditions under which I'd consider possibly allowing for non-tunneled X access. That said, on my own, hardwired, single-user, handful-of-nodes LAN, on the rare cases I do run X apps remotely, I tunnel them. The history of secure applications development is largely divided into two groups: 1. Those who anticipate hostile environments, design for scenarios in which no two components trust one another, and correctly implement failsafe, trust, integrity, and encryption procedures. 2. Those who've been the source of multiple compromises. Paranoia pays off here. Safe practices pay off. Even those who _are_ paranoid and cautious suffer breakins (the good ones will let you know that this has happened). The truely frightening are those who deny the problem exists _and_ fail to recongize a compromise when they see it. Mark, you listening? Peace. -- Karsten M. Self kmself@ix.netcom.comhttp://kmself.home.netcom.com/ What Part of Gestalt don't you understand? Why are you so paranoid, Mulder? Oh, I don't know. Maybe it's because I find it hard to trust anybody. - Scully Mulder, The X-Files, Ascension signature.asc Description: Digital signature ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] xhost+: Why you should NEVER DO THAT
On Friday 18 March 2005 16:12, Karsten M. Self wrote: The history of secure applications development is largely divided into two groups: 1. Those who anticipate hostile environments, design for scenarios in which no two components trust one another, and correctly implement failsafe, trust, integrity, and encryption procedures. 2. Those who've been the source of multiple compromises. Paranoia pays off here. Safe practices pay off. Even those who _are_ paranoid and cautious suffer breakins (the good ones will let you know that this has happened). The truely frightening are those who deny the problem exists _and_ fail to recongize a compromise when they see it. When I first installed firefox it refused to run. After googling about I found the advice to do xhost +. Based on this thread I should have rejected the advice leaving me with two alternatives: 1: download the firefox source and debug it. 2: apt-get purge firefox (followed by a nasty email to somewhere) Richard Harke ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] xhost+: Why you should NEVER DO THAT
Richard Harke wrote: On Friday 18 March 2005 16:12, Karsten M. Self wrote: The history of secure applications development is largely divided into two groups: 1. Those who anticipate hostile environments, design for scenarios in which no two components trust one another, and correctly implement failsafe, trust, integrity, and encryption procedures. 2. Those who've been the source of multiple compromises. Paranoia pays off here. Safe practices pay off. Even those who _are_ paranoid and cautious suffer breakins (the good ones will let you know that this has happened). The truely frightening are those who deny the problem exists _and_ fail to recongize a compromise when they see it. When I first installed firefox it refused to run. After googling about I found the advice to do xhost +. Based on this thread I should have rejected the advice leaving me with two alternatives: 1: download the firefox source and debug it. 2: apt-get purge firefox (followed by a nasty email to somewhere) Have you tried firefox directly downloaded from Mozilla.org? ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] xhost+: Why you should NEVER DO THAT
On Friday 18 March 2005 18:12, Jonathan Stickel wrote: Richard Harke wrote: When I first installed firefox it refused to run. After googling about I found the advice to do xhost +. Based on this thread I should have rejected the advice leaving me with two alternatives: 1: download the firefox source and debug it. 2: apt-get purge firefox (followed by a nasty email to somewhere) Have you tried firefox directly downloaded from Mozilla.org? No, I didn't. Which seems like a reasonable thing to do. But it is not such a small matter. One probably ought to remove or purge the version from debian first, then at some point you will need to uninstall the Mozilla.org version before re-installing the debian version (after the problem is fixed) While I am not rule bound about using only deb packages, I have found that apt-get does a surprisingly good job while my experience with tarballs has varied from easy to nightmare. Richard ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] xhost+: Why you should NEVER DO THAT
on Fri, Mar 18, 2005 at 06:08:04PM -0800, Richard Harke ([EMAIL PROTECTED]) wrote: On Friday 18 March 2005 16:12, Karsten M. Self wrote: The history of secure applications development is largely divided into two groups: 1. Those who anticipate hostile environments, design for scenarios in which no two components trust one another, and correctly implement failsafe, trust, integrity, and encryption procedures. 2. Those who've been the source of multiple compromises. Paranoia pays off here. Safe practices pay off. Even those who _are_ paranoid and cautious suffer breakins (the good ones will let you know that this has happened). The truely frightening are those who deny the problem exists _and_ fail to recongize a compromise when they see it. When I first installed firefox it refused to run. You don't provide any specifics on the problem or why it refused to run. Nor is there a record of your encountering this problem on the LUGoD lists or in Google (based on your first+last name and keyword 'firefox'). I'm going to presume this was Firefox 0.9.x and your problem is similar to that described here: http://lists.suse.com/archive/suse-kde/2004-Aug/0122.html Specifically quoting a readme file: Because of missing registration features in firefox 0.9.x you have to start firefox as root the first time after installation. If you get a message like -8--snip--8-- Xlib: connection to :0.0 refused by server Xlib: XDM authorization key matches an existing client! -8--snap--8-- you have to disable the X authorization with command 'xhost +' and startup firefox. After the initial startup you can close your X session again by 'xhost -' and you should be able to start firefox from now on without problems. After googling about I found the advice to do xhost +. Best I can tell (I don't have the broken Firefox build on my system, and never encountered it), so this is based on general experience: - The xhost advice is unnecessary. The alternative I've mentioned in this discussion -- running 'sux' or as root setting $DISPLAY and merging the user's ~/.xauthority file -- would be sufficient. 'xhost +' is faster and easier, but remains bad advice. I'm not sure if SuSE ships with 'sux', but tool ommissions in other areas on a recent SuSE 9.1 build don't impress me. - This is a fix which is local to the system at hand. 'xhost + localhost' would probably also have worked, and would have _not_ dropped all access security to your X display. - On a sanely configured X server, not listening to external TCP traffic, even running 'xhost +' would not open you up to external hosts, due to your server settings. This is where Mark Kim's advice is mind-bogglingly inappropriate: not only is it overtly harmful (in the event of a misconfigured X server), but (in the case of a correctly configured one) it fails to address the problem at hand. Incidentally, if your X server _is_ listening to external TCPIP traffic, and you haven't explicitly configured it to do so yourself, you _should_ write file a bug report. Based on this thread I should have rejected the advice leaving me with two alternatives: 1: download the firefox source and debug it. That's your prerogative, and I'm sure the Firefox team would have appreciated your contribution. 2: apt-get purge firefox (followed by a nasty email to somewhere) While I suspect there's a hint of tongue-in-cheek in your response, that would have been _fully_ appropriate. Firefox shipped with a broken config (as noted in the README fragment quoted in the post referenced above), and supplied a workaround which is dangerous and highly questionable. You are, however, ommitting the several options available to you for running X applications as root which _don't_ involve inviting the world to your desktop: 3: 'sux commmand' 4: (su|sudo to root) export DISPLAY=display; xauth merge ~USER/.xauthority; command 5: ssh -X [EMAIL PROTECTED] Note that 4 and 5 raise additional issues, I'd deprecate 'su' in favor of 'sudo' as a general rule, and disallow remote root logins. On a single-user system these are less aggregious than the 'xhost +' inanity, but should still be avoided if at all possible (and it most definitely _is_ at all possible). In balance, 'sux' is probably the best mix of sufficient (fixes the immediate problem), safe, and simple. Good security practices are in very large part a matter of making an explicit effort to Do The Right Thing[tm] whenever possible. It keeps you out of bad habits. Being overtly secure when you don't absolutely have to be (personal system, home LAN, trusted network) means that you'll be doing the right thing, by habit, when it _does_ matter. Peace. -- Karsten M. Self
Re: [vox-tech] xhost+: Why you should NEVER DO THAT
Richard Harke wrote: On Friday 18 March 2005 18:12, Jonathan Stickel wrote: Richard Harke wrote: When I first installed firefox it refused to run. After googling about I found the advice to do xhost +. Based on this thread I should have rejected the advice leaving me with two alternatives: 1: download the firefox source and debug it. 2: apt-get purge firefox (followed by a nasty email to somewhere) Have you tried firefox directly downloaded from Mozilla.org? No, I didn't. Which seems like a reasonable thing to do. But it is not such a small matter. One probably ought to remove or purge the version from debian first, then at some point you will need to uninstall the Mozilla.org version before re-installing the debian version (after the problem is fixed) While I am not rule bound about using only deb packages, I have found that apt-get does a surprisingly good job while my experience with tarballs has varied from easy to nightmare. I understand your reluctance. I try very hard myself to install programs only through my distribution's interface. But for FireFox, I think the install is a binary, probably wrapped in a shell script. It shouldn't be as onerous as a tarballed source. But, yeah, it's best if you can figure out your Debian specific problem. Jonathan ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
