https://bugzilla.mindrot.org/show_bug.cgi?id=1733
--- Comment #15 from Philip Prindeville <[email protected]> --- (In reply to comment #14) > Just a further note that having the "system-wide config restriction" is > pretty useless if anyone can copy their own binary onto the system and > bypass it. I suggest having a default in /etc/ssh/ssh_config, and can > can be overridden by the user either in their local config or as an > argument on the command line. And... this is why I think that would be a bad idea. You're fairly typical, I'd say, of most users. You understand what QoS settings are for, and how they can be changed, and what ultimately they're expected to do. But the finer details would seem to have been missed. There are no "standard" profiles for interpreting QoS markings, for instance. There's a proposal (RFC 4594) for uniform markings that ISP's and Enterprises are free to implement, or equally free not to. So you can set your QoS bits to AF22 thinking that this will do what you want, and there's a good chance you'd be wrong: the only person who knows for sure is the Enterprise network architect that provisioned the entire infrastructure. Everyone else is just pulling numbers out of their hat. For *exactly* the same reasons that "PermitRootLogin", "PermitEmptyPasswords", and "IgnoreRhosts" aren't user-settable (because end-users shouldn't be making decisions that potentially impact performance and/or security organization-wide), the QoS bits shouldn't be user-settable either. If users can wreak havoc by having their own profile containing "PermitRootLogin yes/PermitEmptyPasswords yes", then be aware that they can negatively impact organization-wide networking (especially VoIP and IPTV services) by making poor choices elsewhere. Make the compelling argument to me that users should be allowed to have their own .sshd_config file, and put into it those latter two settings, and I'll concede that by the same reasoning they should be allowed to set their own QoS policy. But the bottom line is that QoS markings are as much a part of a site's singular and standardized architectural policy as the type and degree of enforcement of their security measures. -- Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. You are watching someone on the CC list of the bug. _______________________________________________ openssh-bugs mailing list [email protected] https://lists.mindrot.org/mailman/listinfo/openssh-bugs
