Hey Am 29. Juni 2015 14:25:15 MESZ, schrieb Vincent Lefevre < vincent@vinc17.net>: > I completely disagree that passing XTERM_VERSION is not secure > (this RFE is about this particular variable, and not anything else). To be honest, I think it's at best naive to assume, that one can predict whether or not the passing of any such env may be secure or not - at worst it's ignorant. No one can know how a variable may be used on a certain system. While you may assume for your systems, that the xterm variables are only used by that and only on a save manner, another user may interpret them completely different. And only very few variable names have a really standardised (i.e. not just by convention but rather by POSIX or similar) meaning, and this are the only one for which one can assume how they're used. > FYI, this may be useful for Emacs in order to avoid silent file > corruption. Well if emacs does file corruption unless some variable is present, than you should probably file a bug there... > > Otherwise we just see more and more people who have their special > > wishes and sooner or later we end up with "*". > > This is a silly argument. No-one has ever asked for "*". I said "sooner or later"... and you already saw below that there are many further variables for which people may wish to have them automatically exchanged. And VTE is just one of many terminal emulators. Sending XTERM_VERSION would be surely not enough, one would at least need TERM as well, I'd guess. > For ssh_config, I agree that this isn't really necessary, since the > user can have its own .ssh/config settings. But conversely, this has > no effect on the security. This is a wrong claim that you cannot make, except perhaps in your very own limited usage scenario. Actually, I'm quite sure that I've already gave you some good examples in our last discussion about env vars and SSH. Vars like LC_*, VTE*, TERM, etc. may affect how programs (on the server side) produce their output. That alone may already be a security breach, depending on how systems are used (consider e.g. that only certain programs are allowed to run). When the output of such programs is then further parsed by other programs (e.g. run on the server) which decide security critical things, one could possibly break that parsing by setting up locales/terminfo/etc. such way, that it cannot be parsed any longer. > But for sshd_config, it requires a change from the administrator > of the machine, and many administrators will not try to change the > defaults. Or maybe, they simply don't it intentionally. If you want to open up things on your personal systems respectively the systems you use, you should rather go into discussions with the respective administrators, and not try to get the same done by introducing it as default settings in Debian. > Alternatively this could be controlled by a debconf option, with two > choices: > > 1. One that doesn't accept any environment variable (possibly, not > even $TERM). > > 2. One that accepts locale and terminal related variables, which is a > good compromise for machines that support both shell accounts and > specific commands. I have no very strong opinion here. If Colin wishes to make this configurable via Debconf... why not. But the default should rather go to even remove LC_* and at least not adding any further vars - it has a reason why upstream has chosen the default as it is. The problem with your debconf proposal are: - who decides which vars are in the list for the weaker setting - could we accidentally mangle up configs - shouldn't this whole thing be something that the admin/user needs to intentionally configure, rather than having some auto-magic-out-of-the -box™? > I completely agree that one shouldn't pass too much. For instance, > GREP_OPTIONS could be very harmful for specific commands since it > modifies the standard behavior of GNU grep. Than you should also see why all other options, including XTERM_VERSION, LC_*, LANG, etc. are too much - in some or the other way, they all alter the behaviour/output of some programs, behaviour which may however be expected/required/security critical. Best wishes, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature