Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×

Comment Re:Run Linux (Score 1) 451

It's about user choice. See how the parent said "explicitly tell it so"? Yes, you can run vulnerable plugins but only after you are aware that it's vulnerable, and explicitly request to be be re-enabled. The automatic updater is much more effective now than it was before, but it still doesn't force people to update. Mozilla forces almost nothing, including blocklisting (hard blocks aren't possible to override, but those are only used for plugins that crash on startup or are outright malware). If you want someone making your choices for you and not letting you work around them, then perhaps Firefox isn't your browser.

Comment Re:Run Linux (Score 1) 451

Either:
1. There's a bug in blocklisting
2. You are talking about click-to-play
3. You are making it up

Since you couldn't bother logging in, or providing any details other than "wtf it didnt work firefox sux", I can't bother assuming anything other than option 3. Of course, as the courteous AC below you pointed out, you can disable blocklisting entirely.

Comment Re:Run Linux (Score 1) 451

So you're complaining because there's click-to-play, even though they implemented that for all plugins (except the most recent version of Flash). Go complain over here about that, as it has nothing to do with the blocklist. As you so kindly pointed out, though, if you want to be dumb you can shoot yourself in the foot and turn the blocklist off entirely.

Comment Re:Run Linux (Score 5, Informative) 451

Almost all of the plugins are soft blocked. They'll be automatically disabled when you start Fx, but you can easily re-enable them without patching or updating anything. In fact, the same dialog that tells you about the soft block lets you uncheck "Disable" to prevent it from being disabled. Very nearly all plugins that are blacklisted are soft blocked. Their criteria for hard blocking plugins (which means the plugin cannot be re-enabled) is that the plugin either "is malicious" or "a soft-block will not resolve the issue in question, such as a start-up crash". See Mozilla's wiki for more information, especially the sections "A High Bar", "Block Conditions", and "Block Severity".

Please don't spread misinformation and FUD about Mozilla's blocklisting when it really is done properly.

Comment Re:*sigh*.... Java... (Score 1) 270

The distinction between a buggy application, and a malicious application that "asks really nicely" to run as system, is moot. The malicious programmer will purposefully use buggy methods to get the jvm to run at system, exactly because he can then drop shit anywhere he wants. Qed.

Wrong kind of buggy. If you give the installer admin rights, and it installs a program that runs at admin level, that is buggy (perhaps I should have used "improper"?) behavior, but it's neither malicious nor caused by Java. I think we can agree that by granting a program admin rights (either directly or indirectly) it's not obtained improperly. As you said yourself, "This might have been because it needed to be installed as an actual admin, and the system automatically gave it admin privs." Couldn't have said it better myself. The JVM doesn't give Java programs any way to escalate at all without calling C code through JNI or the like, so it's impossible to have malicious Java programs use buggy behavior to escalate. QED. (Of course, malicious Java programs could use some other bug in the JVM to run shellcode or something of that nature, but that's a completely different issue. The target of the attack would be libc, using the JVM as a vector to attack it. In this scenario, though, the program ran at SYSTEM level already, so there were no exploits or buggy behavior in the JVM involved, just an application that required admin rights, probably without needing them as was far too common up until recently, and still is to a degree.)

I want the jvm to have a restriction that says it can NEVER be invoked above a limited super user I define.

I'd say it's possible you might be able to deny the SYSTEM user execute permissions (don't quote me on this, I'm more of a FreeBSD/Linux guy), but again, why should Java be any different in this respect than any other program?

As for the silent invokation, I again refer you to buggy browsers.

Yet again, you're conflating things. The browser plug-in that runs applets is not the same as the JVM. It's part of the JRE, but it's not part of the JVM. The only relation the two of them have is that the browser plug-in uses the JVM to run Java applets in a sandboxed environment. I agree that it should be always prompt (although browser-wide click-to-play is a much cleaner solution IMO), but IIRC it will run signed applets without prompting unless they require special things (FS access may be among them, I don't recall). Personally, I believe the browser plug-in should be opt-in in the first place, but I doubt we'll see that happen.

As for the visualvm listed above, does that come stock? I doubt it does...

It's part of the stock JDK, as it really is a tool made for developers (the JRE isn't targeted at people who want to inspect all of the inner workings of the JVM).

Comment Re:*sigh*.... Java... (Score 1) 270

In another thread you mentioned that a JVM instance was running as SYSTEM. My statement that it was a buggy program that required admin privileges still stands. Unless you can show that the JVM elevated itself (somehow magically, bypassing all access control), it was a buggy program. The JVM is just another program; it only does what it is told (with bugs, just as any program has).

Comment Re:*sigh*.... Java... (Score 1) 270

When I checked the task manager, the jvm was running at a higher authority level than my user.

Then either 1) something got buggered with your JVM or 2) the application explicitly elevated itself somehow (a la UAC today). The JVM does not run as SYSTEM unless it is invoked by SYSTEM. Sounds like a buggy application.

The fact that I can't get a list of what is running insde in a painless fashion

Repeat after me: one JVM instance can only run one program. One process = one program. Just like anything else... If you have one java.exe running, you have one Java program running.

and can't give a global restriction on what the jre and jvm can touch

Use the same filesystem permissions that apply to every single other program ever made. Why is Java special? Again, if it's running as SYSTEM, you have a buggy program. Lots of programs required admin on XP, but no one blamed XP, they blamed the buggy programs. Same goes for Java.

The day that Oracle comes out and says "we obey local security

Done.

and have global options you can enforce

What sort of options? Concrete definitions please.

along with a way to see what the VM is running

Addressed above.

as well as an option to forbid silent invokations

I sure as hell don't want my server to require a GUI to run servers written in Java. This is another one of those "why is Java special?" things. Lots of programs run silently. Keep control of your machine and check running processes occasionally, and this won't be a problem. If someone is able to start Java running a malicious program, they could easily just install Java anyway, or do any number of nasty things. JVM instances don't magically spin themselves up; they start when a Java program is started.

Comment Re:*sigh*.... Java... (Score 2) 270

I don't feel it is trustworthy to leave a VM running all the time

It's really not a general-purpose VM like Linux, Windows, or $YOUR_OS_HERE on VMware, VirtualBox, Xen, or $YOUR_HYPERVISOR_HERE. It doesn't run an OS, just the one Java program it's given. One JVM instance only runs one program. Hell, the JVM works without any sort of kernel-level support, whereas everything moderately efficient requires kernel-level drivers to work properly. (Vanilla QEMU has no kernel-level drivers, but was so slow that KQEMU was developed, and QEMU was later tied with KVM to make it more efficient.)

Of course, that's not even getting into the fact that it's a very common practice to leave VMs running all the time, especially in datacenters. Many people leave Amazon EC2 instances running, I'd imagine almost everyone with a VPS keeps it running constantly, etc. This still has nothing to do with the JVM, because they are completely different concepts, though.

Also, would you be okay with running Java programs compiled to native code with something like GCJ? It doesn't use the satanic JVM, but that won't really change too much (except possibly give you better performance, depends on how well GCJ optimizes and how well HotSpot optimizes).

I have actually seen java applications access areas they aren't supposed to have access to.

As measured by? Hell, define "area." Are you talking across the network, or locally? If you're across the network, how do you know it was Java and not something else on that box? In either case, how do you know it wasn't malware that slipped in somewhere? This sounds like unsubstantiated paranoia.

That the VM doesn't provide me with good tools to see what really is running inside it...

VisualVM.

...and kill naghty processes

Again, I'm pretty sure you're confused about how the JVM works. Each Java program running has a separate instance of the JVM (java or java.exe). If you can't find and kill the process that's out of control, you are doing something horribly, horribly wrong. To summarize, if you don't like Java, fine. (I know I'm not a huge fan of Java on the desktop, and certainly not in browsers...) But you seem to have deeply flawed views on how everything works.

Comment Re:*sigh*.... Java... (Score 1) 270

You seem to be conflating the JDK and the JRE. They are different things. I'm talking about exclusively the JDK. You're talking about the JRE.

That being said, I've never had a Java program run as SYSTEM. It's always run as my user, and I have no idea how in the hell it would magically run as SYSTEM. You also seem to have a fundamentally mistaken view about how the JVM works, but that's a topic for another reply.

Comment Re:*sigh*.... Java... (Score 1) 270

What's wrong with the JDK? I completely understand not wanting the browser plugins (those are where the majority of exploits come into play), but what in the hell sort of problems are you expecting the JDK to cause? It's the developer tools. Does the malware need to compile itself to bytecode (remember: this is Java)? To be honest, if malware is to the point where it can use the JDK on your box, you're pretty much hosed anyway, as local code execution is already required and the JDK doesn't run with special permissions AFAIK. I've had the JDK on my main desktop for years (JRE, JEE, and Android development) without an issue.

Comment Re:Come on, Alan ;( (Score 1) 380

That's what I hate about Ubuntu (well, one of the things at least), but love about Debian. In Debian, the default DE doesn't really matter. You just don't install the default, and apt-get install what you want later. In Ubuntu, you either install the server version (blech) or install one of the {U,Ku,Xu,Lu}buntus and install your preferred environment later after the default is already installed. Sure you can uninstall it, but why bother going through the process of instaling Unity/KDE/Xfce/LXDE if you're just going to apt-get purge it anyway? I'm an i3 person myself, and there's no i3buntu sadly, so I generally avoid Ubuntu even though I love Steam, and Steam only officially supports Ubuntu.

Slashdot Top Deals

If a subordinate asks you a pertinent question, look at him as if he had lost his senses. When he looks down, paraphrase the question back at him.

Working...