On 07/27/2010 05:22 AM, DRC wrote: > On 7/26/10 6:54 PM, Antoine Martin wrote: >> As someone said, you can bypass the restrictions by downloading other >> Xvnc binaries for your platform of choice. (see rpmfind and others) >> So the restriction is just an illusion of "security", and I worry that >> people may start relying on it. >> Not to mention that these "other" binaries might be much worse too. >> >> If sysadmins really want to secure their system, then they are going to >> have to do it properly. Not a bad thing IMO. > Antoine, you're arguing theoreticals. What I'm telling you is that, in > a corporate environment, this does not occur. You don't know how lucky you are then! ;) > We have people actively > and successfully using the security extensions to TurboVNC. Yes, it > requires additional administrative policies. The idea is not to make it > hack-proof. The idea is to make it so that a user will not be able to > casually expose a VNC password. If they've downloaded a custom binary, > then they know that they are violating the policy, but honestly, people > who have real work to do don't engage in such pursuits. Well, I'll bite and argue theoreticals ;) This is true until something doesn't work as expected and they need to use VncAuth for some reason (legacy system or whatever) - and can't wait for the request to go through. I've seen it. Then the workarounds end up doing more damage than good. I am well aware that the other approach (setting only the default to not use VncAuth) has its problems too as it can be used to disclose passwords of unsuspecting users. I doubt there is a perfect solution. > Anyhow, why don't you humor me? If you think the feature is useless, > then why do you care if I add it? I am not the only one who uses this > method of securing VNC, nor did I invent it. Oh, I don't think it is useless at all. And I am not saying you shouldn't add it either - it's not my decision, and it can easily be turned off anyway, right?
It's just that from my perspective, there are some aspects that I am *generally* uncomfortable with: * adding hard-coded paths, although I think this is ok here: it won't fail if the file is missing (right?) and Xvnc already relies on having the correct font path built in. * policies that are fairly easily circumvented - as explained above (the main issue with this one often ends up being how admins/security-compliance end up relying on this policy too much as if it were unbreakable - similar to the way they treat outgoing port filtering on a firewall: they block non http traffic and then just ignore any traffic to port 80 or 443...) * command line options that do not take effect as expected - although that can problably be made obvious to the user, even erroring out if desired. Please don't take this the wrong way, I am only trying to make constructive criticisms. If you think this is not helpful or purely "theoretical", feel free to ignore it! Cheers Antoine > ------------------------------------------------------------------------------ > The Palm PDK Hot Apps Program offers developers who use the > Plug-In Development Kit to bring their C/C++ apps to Palm for a share > of $1 Million in cash or HP Products. Visit us here for more details: > http://ad.doubleclick.net/clk;226879339;13503038;l? > http://clk.atdmt.com/CRS/go/247765532/direct/01/ > _______________________________________________ > Tigervnc-devel mailing list > Tigervnc-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/tigervnc-devel ------------------------------------------------------------------------------ The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://ad.doubleclick.net/clk;226879339;13503038;l? http://clk.atdmt.com/CRS/go/247765532/direct/01/ _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
