This is terrible... before I could at least zoom the text, now if I try the columns overlap and cuts off text.
Exactly! Minimum font size setting in browser makes the site cut off things from the left.
Top of that preferences cannot be saved unless javascript is enabled. Come on guys what is so javascriptish on a SAVE button?
You don't get the point because you don't have my setup, nor did you pay attention to a key word: "graphical". Non-GUI access to my systems isn't nearly as damaging as GUI access to them. For example, if I accidentally leave a document on which I'm working on my desktop, it's not readily apparent via CLI, but you can see it plain as day if you logon graphically. I don't like to take the risk, so a password is a good extra step to provide that security.
What I said is universally applicable. Graphics does not matter. "A password" can be used on private key too. And "a password" will not help you against someone determined to do the damage if they already have access to your account. Unless this is some sort of protection from 9 year olds that is.
my screensaver crashes for some unknown reason from time to time so while
Crashed screen saver usually renders the X session unusable because it would make precautions so that if it crashed then it would not expose working desktop to anyone while you're taking your break. That is at least the old school ones do this, maybe the new fancy ones don't
My sshd_config has PasswordAuthentication = no. Nothing can login via ssh(not even 127.0.0.1) without the proper PK.
Then the documentation lies...
I do agree they should generate a new key upon install.....and they offer that as well. If you read a bit more there's a step in the setup that asks if you want to use the default key pair. If you answer "no", it'll generate one for you. Are you sure you used NX for any *real* period of time?
Yes I devoted some fair time to make it working. (I failed on the PK auth step.) I installed the open/free version from packages so there were no questions asked. Hey maybe I am wrong and all crap like this has already been fixed - good for you/them/whoever then. But back then I assure you it wasn't just any one thing that pissed me off, it was the whole concert of them.
I personally like the password because that means that someone can't get unchecked graphical access to my remote machines by simply catching me on a bathroom break with my screen unlocked. In your scenario it would only take a single click. Yes, they would have access to my laptop but I'd rather have at least a password between them and access to the remote systems I admin.
I don't get the point here. You leave your screen unlocked then I gain instant access to where ever you're currently logged on. Plus I can stick a neat backdoor to your user account to automagically hijack all your further sessions (if time allows, depending on the magnitude of bathroom service you're utilizing...)
So please leave your screen locked. (BTW even if you lock it I can stick a key sniffer to your keyboard and pwn you anyway.)
Anyway what you probably originally meant is that PK auth is passwordless. Well it can be used that way but you can also put a password on your private key. Then you have to type that password in order to auth. The key difference here is that neither the password nor the private key leaves your computer and the login is unrepeatable without possession of the private key. That's in contrast to classic password auth where the pw is sent to the server where it can be sniffed and re-used. So what I meant in my original post is that in 2010 there is really no reason to use oldschool insecure auth methods.
Also, I don't think that you have the NX login sequence entirely correct because while the first part seems accurate, I can safely say that NX can NOT be spawning a second ssh session using my password because passwords are forbidden in ssh by policy on my system, so it'd have to be using my PK, or doing some other form of login.
Okay my experience with NX is about 18 months old and on behalf of this discussion I re-checked their docs today. It seems there is another way, that is using an internal database of users. The relevant source is http://www.nomachine.com/documents/admin-guide.php section 4. So either you're using that option or you should really re-check your SSH logs and config
I don't ever remember being encouraged to keep the same public key for NX but I can safely say that my setup uses my own PK.
Now I can't find the reference but I swear I saw a paragraph saying something like if you replace the keys then out of box installs will not connect blah blah. Yeah I hear you say "big deal" but ffs this is about serious loss of security so there should never be a default key thus negating the necessity for mentioning "replacing the default key" somewhere in the manual. The keys should be simply generated at install time, with a message popping out "give this [public key content] to any Joe Schmoe you want to access that server of yours".
And just to let anyone know who might be interested in setting up RSA PK authentication with NX, you have to use NoMachines node/server/client from their site, the FreeNX/OpenNX only do DSA.
Sounds weird to me, why the heck would that be so? Both use the same ssh, which supports both.
the NX login requires a password regardless, I assume for security measures
Ouch. Getting your password transferred to & used at arbitrary locations is hardly more secure than the challenge/response PK schema in which your secrets never leave your computer.
IMO the reasons behind this are merely laziness/incompetence on top of bad design.
I personally am cool with that
I am not. First of all it is un-secure to enter your password somewhere without really having control of where it goes.
Second, it is a pain in the ass. Even if you use PK for all your ssh access you will have to maintain a password just for nx sake. Come on in the year 2010 (or 2011 for that matter) it is totally idiotic to use ssh with passwords for normal daily jobs.
That's why NX made its way out of my door very shortly after trying it out.
If you want to know the whole story then read on.
What really happens with NX is that your client first opens a ssh session to nx@server - this session uses PK auth. Unfortunately the private key is well known, as it ships with a default one and almost noone bothers with replacing it (in fact it is not advised - lol). That means anyone in the world can open that connection to your server and get authenticated and proceed to step 2.
Coming to step 2 after logging to your server as user nx the nx server program is launched. This program actually manages translating the X window protocol to the nx protocol - all the "compression" and stuff. It will set up a DISPLAY variable to point to itself and then launches ANOTHER ssh to you@localhost (localhost being the server). That's where your password comes in.
After that X applications (usually the whole desktop) can be launched under your account, they are going to talk to the sshd spawned by ssh @localhost, where the X protocol is encrypted and compressed, shortly afterwards decompressed and decrypted by the nx server running the ssh command, then translated to nx protocol, encrypted and compressed again through the ssh session for user nx all the way to your client pc where finally decrypted, decompressed, translated to X and displayed on your screen.
As you can see the weird part here is the user nx running the nx server. It is technically absolutely possible to avoid at all this step. The nx server could be easily launched on behalf of the user with the applications spawned from there. IIRC the introduction of the nx account is something as ill as licensing.
Even with the nx account present it is totally irresponsible to leave it protected by well known PK, for the sake of making the installation & deployment 2 clicks easier. The impact is that anyone can launch a nx server on your server. They claim it is secure - hah. At the very least you can start brute forcing passwords for local users, at the other extreme you can find a neat hole to hijack the process and make your way in to the system. Combine with the knowledge of some kernel loophole and you can start scanning for nx enabled systems all over the internet with satisfaction guaranteed.
And even with the ssh@localhost weirdness it is feasible to use PK auth, either by use of ssh agent or some sort of channel forwarding. But no, that's not supported, because...
... enter the customized ssh client shipped with nx which one of the steps involves. Being customized it is never kept up to date so say goodbye to features and say welcome another lot of security holes.
And finally when I read the forums about the open source client wondering if all this mess was fixed at last, I found out that it wasn't/won't - for COMPATIBILITY reasons.
Sad story.
Then I removed the RAM to bring it down to 256k, and it still ran decently (for single tasking).
That shouldn't work. Rumor there is that win7 requires at least 640k.
Back then I ran Gentoo so fine tuning your kernel was the norm, and I genuinely believed the terrible performance was due to bad choices I made selecting kernel options. About six months ago I finally abandoned Gentoo and the entire practice of too-tooing with the internals, and switched to Ubuntu, accepting defaults all the way. No I/O improvements noticed. WinXP on the same machine kicks ass.
I first noticed this problem around 2.6.30 where it would terrorize the owners of then-current mainline distros such as the already mentioned Ubuntu. I think there are 2 problems with I/O though:
Lack of general responsiveness with I/O on the background - for example choppy mouse cursor movements, laggy response for keyboard typing - this can be remedied to some extent by using a preemptible kernel and clock at 1000hz and I think it's generally gone after the (proper) low latency hack since 2.6.33 or so.
The other one is crappy work with disk request queues and/or bandwidth, usually when there is one big transfer then all the other stuff has to wait, and there is no way to tell the kernel to do otherwise. A lot of stuff needs disk these days - for example start typing URL in firefox, he has to go to on disk db to fetch completions - thus this one can be particularly annoying. I think this is hardware dependant bug (on some chipsets it bites more) and also there have been some tries to remedy it, namely the I/O stalling patch, which AFAIK has not been yet fully merged and is *maybe* going to go to 2.6.37.
All in all I would call the past year as a pain in the ass of the linux desktop. Especially with distro kernels and their blind shoot in the dark style patches. Custom kernels are highly encouraged.
a lot of people don't use it just for Farmville
Now this is news. What, did they put up another game?
Every distro can have iptables installed, not all distros do it by default and/or make use of it.
SELinux is not a distro, it is a security module that controls what applications can do, somwhat like normal UNIX security. For example under UNIX you can't open port < 1024 unless you're root, and under SELinux you can't open ports unless explicitly stated in the system-wide policy. Very few distros use SELinux by default however.
You can even combine iptables and SELinux with SECMARK whereas you use iptables firewall to mark packets and SELinux to deny or allow a certain packet to a certain application.
Just to clarify I understand that there are two zero day root-providing bugs. (Everyone talks about THE bug.)
CVE-2010-3301 patched by http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=36d001c70d8a0144ac1d038f6876c484849a74de and http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=eefdca043e8391dcd719711716492063030b55ac
CVE-2010-3081 patched by http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c41d68a513c71e35a14f66d71782d27a79a81ea6
In practicality, the amount of code to perform expansive unit tests quickly dwarfs the amount of code in the product you are testing.
Obviously you write only these that cover some important bugs/functionality. Privilege escalation bug is enough justification.
Like the summary said, the old attack didn't work exactly, it had to be tweaked slightly. Even if you had a unit test for this situation, it most likely would have passed (meaning the test exploit would fail).
That would be true if you wrote a test for the full exploit which is *not* a unit test. A unit test would cover the source of the bug (as opposed to its consequences), that is, ensuring top half of %rax is zero when looking up the syscall table (or just ensuring that %rax is always < nr_syscalls). That sort of test would catch the regression.
Look at things they have done! Not just the outside, check the code, look at the database structures etc.
Especially look at how they write the automated tests, if they do so at all.
As long as my computer and the server I connect to are malware free asymmetric cryptography (public-private keys) prevents an attacker from eavesdropping on the session.
False assumption. The endpoint PC is compromised in way more cases than the middleman router. Encryption alone buys us nothing. Or wait -- it buys us key manangement hell.
60 Check for typos 70 Check for grammar mistake
You must be new here...
I have hardly ever known a mathematician who was capable of reasoning. -- Plato
