Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror

Comment Re:Proposed solution (Score 2) 133

Just send all the Muslim refugees to college for free.

Oh, we will. You can count on it.

If they are accepted as refugees, after a few years they will be eligible for the same benefits as other citizens. Danish education - including college education - is free. Not only that, but we will even pay students scolarships of around DKK 5100 a month (apx $9200 per year) to cover living costs.

Universities have admission criteria, however. You'll have to be accepted. Most citizens with muslim background seeking higher education tend to go for the types of education that traditionally have high status in their culture: Law, medicine, dentists etc.

I have a high wage. I pay a *lot* of taxes. Do I mind that refugees seek education in Denmark and receive benefits? No, I do not. Any qualified young man or woman seeking higher education is *exactly* what we need. If they're qualified, I'm happy with paying my taxes so that they can receive an education even if they come of circumstances very unlike mine.

Right now we're receiving both refugees and migrants. We are well aware that the generous welfare systems in the Nordic countries and the economic opportunities (and welfare system) in Germany is attractive. Obviously, the Nordic countries cannot open the borders and let in every needy person in the world.

Bit the ones we *do* let in considered needy. And they *will* be eligible for the same benefits as the rest of us. And I'm kind of proud of that. And yes, I pay my high taxes with pleasure. Makes me feel good about it.

Comment Re:The end (Score 4, Insightful) 133

The Nordic welfare states are dropping like flies.

Eh? By "the Nordic welfare states" I'm assuming you mean Denmark, Sweden, Norway, Finland?

Let's examine that claim. Sweden is doing great, Denmark almost as great. Norway has the oil (and a *lot* of it) and has had the god foresight to save oil money from the good times to insulate against poorer times. Norway is doing exceptionally great. Which leaves Finland. Sure, Finland has challenges which can be attributed to a disrupted monoculture. But they are not dismantling the welfare state by any means. They're innovating. None of the Nordic countries are about to "drop" like a fly.

I don't know why you would try to paint a picture of the Nordic welfare states failing. They're not. Not by any stretch of imagination. Do you live in a place where successful welfare states would be an inconvenient counterpoint to your political point of view?

Yes - there's challenges in the Nordic elfare systems, like with any other model. Right now the Nordic welfare states (and the German welfare state) are under pressure because a lot of migrants would like to live in a place with generous social benefits, free education (and at least in Denmark you will even receive full state-paid scholarship all the way through college), free healthcare, retirement welfare etc.

Other countries have other challenges. In the US the average middle-class income has stagnated sinde the 1970ies. The wealthy are getting wealthier, the middle-class is struggling and the poor has gotten even more poor. US social mobility has degraded to a level where "the American dream" is but a distant fantasy.

Comment Re: Linux is a fragile house of cards (Score 1) 698

You can't do the same thing in OS X. I don't know about Windows.

Windows has had Resource Protection since Vista. Even before that, Windows File Protection going back to Windows 2000.

Only Windows Update can run as "Trusted Installer" - and only trusted installer is allowed to replace or change system files.

Comment Re:Linux is a fragile house of cards (Score 1) 698

Well I gotta tell you I've seen programs removed and suddenly the system would not boot on Win7. Seems the uninstaller took a few system files with it. Shitty developers can fuck up absolutely anything.

On Windows, uninstallers cannot delete system files. Since Vista, Windows Resource Protection has prevented even processes running as administrator or SYSTEM from changing/deleting system resources (files, registry keys etc). Only the "trusted installer" account can write those files, and only the WindowsUpdate process runs as trusted installer. It will not install 3rd party applications.

Not saying that an uninstaller cannot do other harm which could toast the boot process, but it cannot delete system files. Safe mode will trust *only* system files, and should always be able to load - bar hardware failures.

Comment Re:Gonna get lambasted for this but... (Score 2) 698

I don't know that because it is a tiny little bit harder to do in windows, that it makes systemd the bad guy in a UEFI fault.

You can not accidentally write to those variables in Windows when trying to format a disk or do other admin work.

The problem is that systemd has put those variables directly in harms way. *Never* would you expect that removing all files from a file system would delete variables outside the operating system - in the firmware.

The file system is *owned* by the operating system, which is a subordinate of the firmware. The control chain goes: firmware > boot-loader > operating system > file system. For the file system to cause damage to the firmware is a design bug, even if the endpoints to do such damage has been exposed by the firmware.

Comment No, the problem is the Unix "everything is a file" (Score 2) 698

The mental model of a file system - the expected behavior - is for it to be hierarchical. We silently expect anything below a certain path to be subordinate. Already this model is broken because devices can be mounted, files symlinked/hardlinked etc. That something much more fundamental to a system than a file system directory can be found deep in the hierarchy is a violation of the hierarchy.

That's why it is surprising that removing everything from the file system may cause higher order information to be deleted as well. You do not expect that. The impulse to map everything to a file deep in the filesystem is dangerous.

Sure, you can probably write/destroy UEFI variables from windows, but not as unintentional collateral damage from deleting a directory.

Comment Re:LOL, what? (Score 2) 698

It's worth noting that, according to ex-kernel hacker Matthew Garrett, you can achieve the same bricking using a 20 line program in Windows.

You mean to say that if I accidentally type that 20 line program on Windows, compile it, type the name and hit Enter, my box is toast? That's scary!

Thanks for the warning. I'll be wary of those 20 lines. What were they again, just so that I do not type them accidentally?

Comment Re:Windows 98-XP (Score 0) 91

But is it really an upgrade? Doesn't the MS installer just installs a clean XP next to 98 and renames the Windows folder to Windows.old?

Yes, it is upgrades: The Windows.old directory is for safe-keeping. The OS itself has been upgraded. True, in the case of 98 => XP it means replacing everything. But an OS is tasked with managing hardware devices and running applications. All relevant settings as well as compatible applications are carried over thanks to the registry (yes, the registry!). User files and data moved to the correct locations.

Comment Please, it is getting old.... (Score 2, Informative) 34

The updates to telemetry do not suddenly cause Windows to start sending information back to Microsoft. Only when the user has explicitly accepted CEIP (Customer Experience Improvement Program) will these updates have any effect on a system.

If you have not activated CEIP, the updates will not cause any information to be sent back to Microsoft. It is that simply.

https://support.microsoft.com/...

Comment Re:Article is bullshit (Score 5, Interesting) 170

Nothing to do with java. Buffer overflows are quite possible with java, but this problem has everything to do with shitty coding, not the implementation language.

No, but this problem has everything to do with shitty operating system design. The login "screen" should not just be an application that maximizes it's screen to cover the UIs of all other application. That is a naïve implementation, and it opens the supposed security feature up to all kinds of attacks, including shatter attacks and more. Not to mention that an application crash will cause the OS to clean up and close the "blocking" window.

Google should take a cue from Windows and make the login screen a totally separate "desktop" which is completely isolated from the "user" desktop. Switching between the two should be a privileged operation, one that can only be executed by trusted login applications. This way a mere exception will not cause the "login" program to crash, close and reveal the user desktop.

Comment Re:The same basic approach works everywhere (Score 2) 123

It is isolated. In order to interact with it, a user must explicitly permit it by entering an admin's username and password.

Sorry, but that is not isolation. If the prompt require a password rather than just an accept, the launching process can *still* control it remotely through Applescript - it would just not know what to put in the fields. That's not isolation. At best, it is a mitigating factor.

Isolation would mean that any Applescript launched from the process was *barred* from interacting with the approval window.

The vulnerability here is architectural: Windows can be remotely controlled. Ask yourself this: What good is an approval window, if the process can just remote control the approval itself?

Comment Re:The same basic approach works everywhere (Score 2) 123

On OS X, this programmatically easier to do, but it's possible with a little more effort in Linux (if using GNOME or KDE and their password stores) and Windows (which is trickiest of all since you specifically deal with an application's store rather than a central one; presumably you'd go for a browser)

On Windows - unlike on OS X and Linux - there is the concept of User Interface Privilege Isolation (UIPI) where a process running with a higher integrity level cannot be remote controlled by a lower-integrity process.

The real vulnerability here is NOT whether the user has allowed the process to run or not or whether it came through the app store nor not. The critical vulnerability is the lack of isolation of the window that is supposed to obtain approval from the interactive user. This lack of isolation means that an OS X application can launch an action that requires approval and then immediately - through script - approve the action itself.

Pointing to the app store approval model is missing the point entirely. Even approved applications can (and do!) contain vulnerabilities. The reason why so many apologists are out in force and try deflecting the problem as "app approval" is because this illustrate an architectural problem within OS X: Even though the same user runs a number of processes, a mechanism for policing what they can do to each other is lacking.

Comment Re: To be expected (Score 2) 246

But not a system default one.

As of Windows 10 (and soon previous versions with Windows Management Framework 5.0) there *is* a default one: OneGet - now just called "package manager". It is controlled through a PowerShell module. It is actually a package manager umbrella, as it can be used for a number of different package managers which can provide "providers" for PM and integrate that way.

Open a PowerShell prompt and type the following to reveal the commands of the PackageManager module

        gcm -mod PackageManagement

(or type gcm -m pack[tab] if you want to save keystrokes - powershell will autocomplete the module name)

To register Chocolatey as a package source (so that you can find packages through Find-Package) type this:

        register-packagesource -Name chocolatey -Provider PSModule -Location http://chocolatey.org/api/v2/

Comment Re:For the love of... (Score 2, Insightful) 56

When is MicroSoft going to get off their butts and fix their operating systems so that the first user is not defaulted to administrator rights or at least have the first user forced to make a 'normal' user account for normal usage? Even 'ancient' Linuxs only add the first user to sudoers so that they have to explicitly invoke rootly powers.

Unlike Linux, Windows uses proper security tokens. Each process has it's own token governing what it can do to which resources. On Linux the "token" is - rather naively - a user id.

When you log on to Windows - since Vista - with an account with administrative rights, thee token that is created for the shell process is 1) stripped of all administrative rights and 2) given an integrity level of "normal". Integrity levels are also part of the token.

What it means is that *even when you log on as an administrator* you do not possess any administrative or god-like rights. You are a standard user.

When you invoke a program that has a manifest which states that it requires some form of administrative rights, Windows will prompt you for "elevated" privileges. Only when you accept to use your administrative privileges will the process be started with a token with higher than standard user rights.

It really is a much more elegant solution than the stupid effective user in Linux, where the description of a process rights is strongly tied to a user: There must exist a user with the specific sets of rights you want the process to have. Not so on Windows: Any process can have it's own token with fewer or more rights/privileges.

You can turn off UAC (don't!), which is why Microsoft must write the disclaimer *If the current user is logged on with administrative user rights*. If you turn off UAC and log in with an administrative account - then you run all processes with full permissions/privileges.

When is MicroSoft going to get off their butts and fix their operating systems so that the first user is not defaulted to administrator rights or at least have the first user forced to make a 'normal' user account for normal usage?

They did fix it. You are just ignorant.

How many of these problems could be mitigated if this were not MicroSoft's default approach?

The answer is 92% - and it is mitigated by default.

Slashdot Top Deals

"Life is a garment we continuously alter, but which never seems to fit." -- David McCord

Working...