Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

×

Comment: Re:What could possibly go wrong? (Score 1) 114

by swillden (#49182821) Attached to: Linux 4.0 Getting No-Reboot Patching

If someone gains root, they can swap out the on-disk boot image that contains the kernel, and wait for someone else to reboot it as part of normal maintenance.

Assuming there isn't something that prevents the boot image from being replaced. See my other, more extensive, comment in this thread.

Comment: Re:What could possibly go wrong? (Score 3, Informative) 114

by swillden (#49181487) Attached to: Linux 4.0 Getting No-Reboot Patching

But what you're saying is that rebooting is somehow a magic cure-all that guarantees the system isn't infected somehow

Don't be condescending. I'm not saying rebooting is a magic anything.

Whether or not this matters depends on the threat model and why the attacker is interested in patching the kernel. For example, one purpose would be to disable other kernel security features, such as SELinux, or dm-verity. Most SELinux rules are configured and the configuration can be altered by root, but some are compiled into the kernel and can only be modified by modifying the kernel. Altering the persistent kernel image may not be possible for a variety of reasons (read-only media, SecureBoot, etc.). In addition, in security-sensitive and mission-critical contexts an unexpected reboot may well be noticed.

I don't understand your assertion about SecureBoot. Are you referring to some known vulnerability of some particular secure boot system? Given a decent implementation of secure/verified boot, an attacker should not be able to convince the system to boot a modified kernel image, which means that run-time modification of the kernel is the only option if the attacker needs to bypass some kernel security enforcement.

In general, the security model of a high-security Linux system assumes that the kernel is more trustworthy than root. The ability for root to modify the running kernel invalidates this assumption, which most definitely is a security issue.

In the context of a system without mandatory access controls there may not be any reason to care, since once an attacker has obtained root there probably isn't any limit to what he can do.

Comment: Re:What could possibly go wrong? (Score 2) 114

by swillden (#49180351) Attached to: Linux 4.0 Getting No-Reboot Patching

It's no more a risk than current patching that requires a reboot, except that you don't have the downtime of a reboot.

Sure, if your concern is error, rather than malice. An attacker who gains root could use this to dynamically patch a backdoor into the running kernel. Rebooting the machine would potentially enable someone to notice.

As another poster noted, though, you can already dynamically patch the kernel for malicious purposes by loading a malicious module, assuming that hasn't been disabled. In contexts where security is crucial, I would disable both dynamic module loading and run-time patching.

Comment: Re:Pretty pointless (Score 1) 321

by swillden (#49179733) Attached to: Ask Slashdot: How Does One Verify Hard Drive Firmware?

I assume the communication companies were handing over a lot more than the NSLs can demand in the spirit of cooperation and that is why the retroactive immunity was necessary

The GP wasn't suggesting that excessive data was handed over, he said that an NSL could be used to demand installation of a backdoor. If I were a vendor, even one who really wanted to be cooperative, I'd balk at that, because the chances of something like a backdoor being discovered are too high. It would be actively sabotaging my customers, and not just to the NSA... a backdoor can't distinguish between users, it lets in anyone who figures it out. And, of course, if the existence of the backdoor were published it would do serious damage to my business.

Even companies who want to cooperate are going to be reluctant to do potentially business-destroying favors for the government. There would be a great deal of incentive to fall back on the law and refuse on the grounds that the law doesn't authorize such requests.

Comment: Re:FDE on Android doesn't work as of yet (Score 1) 116

by swillden (#49179701) Attached to: Google Backs Off Default Encryption on New Android Lollilop Devices

I'm skeptical that an Android device would survive running flat out for two years to crack a PIN. The heat and battery life issues I experienced when I tested it demonstrate clearly that mobile devices simply aren't designed to run full-speed 24x7.

Also, it should be pointed out that the attack I described is far from easy to carry out. Among other things, it requires dumping the contents of flash, which basically requires removing the flash chips from the mainboard without damaging it, then either putting the flash chips back or installing new flash, then the device must be unlocked, a custom, hostile OS flashed, and finally the attacker can start the multi-year process.

Note that the 630-day figure I cited is on average. It would take twice that long for a guaranteed break.

Finally, if you add one more character to your passcode (7-character alphanumeric), the crack time jumps from 630 days on average to 124 years.

I agree that Lollipop FDE still needs some improvement, but it's already quite good.

Comment: What's the key spacing? (Score 1) 54

by Ungrounded Lightning (#49178401) Attached to: A Versatile and Rugged MIDI Mini-Keyboard (Video)

Is the key spacing the same as a standard piano keyboard? If not, how does it deviate?

Can it, in combination with some particular, commonly-available, MIDI software package(s), be programmed to have the same touch characteristics and sound as a piano, harpsichord, etc.? If so, are the configurtation parameters to produce equivalent performance already available?

Comment: Re:It's not the PC microphone ... (Score 1) 90

by Ungrounded Lightning (#49177877) Attached to: Ask Slashdot: Wireless Microphone For Stand-up Meetings?

Or bypass the problem completely by using a USB microphone. These digitize the audio right next to the microphone proper, with everything floating at the same voltage so nothing substantial is picked up betwen the air pressure sensor and the A-D converter.

Bluetooth headsets work great for this, too. Most current generation laptops already have the bluetooth central-role radio onboard. Or get a cheap low-profile bluetooth dongle.

Comment: It's not the PC microphone ... (Score 1) 90

by Ungrounded Lightning (#49177857) Attached to: Ask Slashdot: Wireless Microphone For Stand-up Meetings?

4. PC/laptop microphones suck. I don't know why no one bothers to test them to the same level as your average cheap dumbphone speakerphone. They pick up all kinds of system electrical noise, ...

The problem usually isn't the microphone. It's the way it's wired (per the standard) and the way the desktop/laptop is powered.

PC microphones are wired UNbalanced: They have a signal and a ground wire, rather than the + and - signal wires and everything-but-desired-signal cancelation of the balanced wiring setups typical of professional microphones.

Laptops typically use power supplies that are not grounded, so they don't require a three-prong outlet. This usually ends up with the stray capacatance to BOTH sides of the line wiring capacitively coupling equally to the laptop "ground". That means the "ground" of the laptop is at half the line voltage - about 60 volts of AC (a rotten approximation of a sine wave plus lots of other junk it picked up at an assortment of frequencies). The capacitance is substantial - not enough to shock you if you touch the laptop and ground, but enough to feel a buzz if you rub your hand lightly across a "grounded" metallic part of the device.

Plug in the unblanced microphone and hold it, put the headset on your head, or just leave it sitting on the table. The "ground" is at 60V and you are driving maybe a couple MA of it down the shield wire. The voltage drop of that current (along with any other pickup) adds straight onto your audio input. The best microphone in the world will perform horribly if hooked up this way.

Try this: Unplug the laptop and let it run on battery. Notice how almost all of the noise disappears. You can also get rid of most of the noise by tying a decent ground onto the laptop. (Unfortunately, many meetings last longer than the laptop batteries...)

Plug in a VGA monitor with a three-prog power plug, which grounds the case of the laptop via the shield and the two hold-in screwd. I've done that without actually hooking up the monitor (which would have disabled my laptop screen) by adding a couple of the nuts scavenged from another DB connector as conductive spacers so the actual signal pins are not quite into the plug. And done this on a docking station, so the laptop headset was quieted when the laptop was docked, even though I used none of the docking station features except the power input.

Make a second cable with a three-prong plug to bring a ground up to the laptop. Green wire from the third pin to a screw into or clip onto such a chassis ground point.

Or bypass the problem completely by using a USB microphone. These digitize the audio right next to the microphone proper, with everything floating at the same voltage so nothing substantial is picked up betwen the air pressure sensor and the A-D converter.

Comment: Re:you can do osx and ios in c++ (Score 1) 387

by rjh (#49177343) Attached to: Ask Slashdot: Which Classic OOP Compiled Language: Objective-C Or C++?

Cfront worked by translating C++ into C, which was then run through a C compiler. As such, cfront had to be abandoned in the early 90s because there were certain syntactic structures that simply couldn't be expressed in a reasonable amount of C source code.

The original poster is (mostly) correct. Cfront was a compiler only in the sense that it did a transform of one language (C++) into another (C). It was not a compiler to any extent beyond that; compiling to native code was left up to the system C compiler.

Where the original poster is wrong is calling C++ a "preprocessor for C". That's a reasonably-correct way to describe one early implementation of a C++ compilation system, but it's not an accurate way to describe the language itself.

Comment: Re:Bad idea (Score 1) 631

by swillden (#49176897) Attached to: Snowden Reportedly In Talks To Return To US To Face Trial

Civil disobedience has ALWAYS carried the potential for punishment and if you break the law to make your point that the law is unjust you should stand ready to be arrested, imprisoned and tried in court for what you choose to do.

Your argument would carry more weight if the government who'd be trying Snowden weren't the same one he outed for violating its own laws, with the active collaboration of its judicial branch. Not to mention all of the recent fully-public sidestepping of due process for hundreds of other enemy combatants. Oh, and the torture, including of US citizens. And... do I really need to go on?

Snowden has extremely good reason to be skeptical of the fairness of a trial... or if he'd even get a real trial.

Comment: Re:Leverage (Score 1) 631

by swillden (#49176761) Attached to: Snowden Reportedly In Talks To Return To US To Face Trial

Snowden may be using what leverage he has left. He has not yet disclosed all the information he obtained so the US government might cut a deal to avoid further disclosures.

I see no evidence that Snowden didn't hand everything over to the Guardian et al, all at once, as he said he did. On what do you base your claim that he's still got something left?

Comment: Re:C++ important on Apple too (Score 1) 387

Cross-platform compatibility of C++ code is excellent these days, C++ can call low-level Apple APIs exactly as well as C, and there is no performance cost to C++ unless you choose it.

1) Good but not as good as C.

In most cases these days it's a distinction without a difference.

2) But it's an unnecessary third layer. Obj-C has the objects. C has the speed and compatibility. What do you need a third layer for?

I see this differently. Obj-C has the objects I need to interact with the framework. C++ has the speed, compatibility and expressive power I want. C has speed and compatibility, but lacks expressive power, which creates a lot of tedium and loses a lot of safety.

3) Indeed.

We agree on something :-)

So virtually no one uses it in this scenario.

Only time I see it used is when it's a library that was written in C++ on another platform and is simply being used on a Mac.

I haven't really done much on Macs, but I did a lot of work on NeXTstep back in the day, and C++ was quite common in scientific computing there. Actually, what I saw a lot of was "Objective-C++"... they may have grown further apart, to the degree that this no longer works, but in the early 90s gcc allowed you to mix Objective-C and C++ constructs freely in the same code. So a common approach was to build everything in an OO fashion, but to choose between Objective-C and C++-style classes based on performance and flexibility tradeoffs. The result required you to be fluent in both, but that really just means being fluent in C++ because a C++ programmer can learn Objective-C in a day (which is something I respect about the language).

Due to lack of disk space, this fortune database has been discontinued.

Working...