The government will always have the same access to a you a random stranger does because the government is made up of people.
Not really true. On the one hand, the government has the resources to wiretap your phone, for example, in a way that a random stranger cannot. On the other hand the government is constrained by various laws that restrict the information they can gather and use. For example in Europe at least data protection legislation restricts sharing of information between government departments, so even if the government as a whole knows several things about you it is unable to correlate them to reach conclusions. You can tell this data protection legislation is having a real effect because the British government wants to give itself the power to override the legislation.
non-technical users always finding new ways to download and install software on their home dirs that behaves badly over NFS.
Do you have any examples? I have installed all sorts of stuff in my NFS home directory and never had trouble with it. But then, I'm surprised that non-technical users are able to install Linux software at all. What are they getting?
Why do netbooks need a new name? It's a well-understood and generic term, just like biro or (in some countries) hoover. Let the lawyers deal with the lawyer-crap.
The usual answer is to write the core of the application in a relatively low-level language and add a scripting extension which can be used for less CPU-intensive, more rapidly-developed parts (often including the UI). The split between 'core' and 'extensions' varies but some examples are:
Firefox: core C++, UI and many extensions in Javascript.
Emacs: a small core in C, almost everything in Elisp.
Core in Java, scripting in Jython or another language that compiles to JVM bytecode (eg IBM Websphere)
Core in C#, scripting in IronPython, IronRuby, etc.
Core in C, scripting in Scheme (The Gimp's original Script-Fu, see also Guile)
There are other languages designed to be plugged into a C or C++ program, for example Lua and Tcl. You can even embed Perl though it's a little more complex.
Same here. I would never give money to the NSPCC but I'm happy to support Barnados. I hope we can get them to change their mind on the subject - or at least, recognize that political lobbying is not one of the functions of a children's charity.
I was pleased to see that my ISP, Zen Internet, is one of those refusing to bow to the IWF. I will continue to recommend them to friends and family as a sensible, human-run provider.
You are quite right that Javascript in PDFs is a lame idea, and executing it automatically is even lamer. However, even without Javascript or any other embedded programming language, the PDF viewing code (as a very popular program, presumably written in an unmanaged language, which needs to read a complex binary file format) still ought to be sandboxed to reduce the damage caused by future exploits.
And why exactly does Adobe Reader run with full permissions to all the user's files? Surely by now Adobe would have learned to run it in a sandbox. For example, the code that reads and renders the PDF could run in a separate process (a la IE8 or Google Chrome) and just send image data back to the main window.
More generally, the OS needs to make it completely easy to sandbox applications, so even the stupidest application developer can do it with little effort. Indeed, the default should be that it has no access to write files anywhere except those chosen by the user with the Save As box. I'm not holding my breath though...
I have found maintaining and updating a perl installation using rpm and yum to be considerably more reliable than the CPAN shell, which tends to trip over with build failures or mirror site failures... YMMV. I don't think it is practical however for every Mac across the globe to download files from the CPAN mirrors, including all the extra packages needed to get 'Build' and 'Build test' working, and trust that every Mac will build the package correctly without odd bugs creeping in. At least with distribution of binary packages you know what you're getting. Even Linux vendors (with the exception of Gentoo) ship pre-built packages for everything; I can't imagine Apple doing anything else.
since when have any two package managers gotten along?
Never. My point is that having two different package managers operating on the same file is a bad idea. Each should keep to its own business and leave alone files managed by the other.
On a modern Linux distribution, it's actually okay to modify stuff that the vendor sends you, provided you do it using the same infrastructure as the vendor. For example, on an RPM-based system, you can easily build and install your own local RPM packages, with dependencies and all that, and they integrate nicely with the vendor-supplied ones. I wanted a newer version of the Perl LWP library than was in Fedora 10, so I grabbed the source RPM, updated it and built my own RPM package which I installed. Fedora then won't overwrite this unless they push out an even newer LWP release. Exactly the same can be done with dpkg-based systems.
If your vendor is incompetent, or you are paranoid and don't trust them, or some mixture of the two, then there may still be political reasons not to alter the vendor packages and instead put duplicate copies in a different directory. But nowadays there aren't always technical reasons why you shouldn't.
Why are Apple's updater and Perl's CPAN shell both trying to update the same file? If the file's there as part of the Apple OS then only the OS's package manager should touch it, and Perl should leave it alone (installing its own version in/usr/local if necessary). It's exactly the same on Linux distributions: the CPAN shell doesn't try to mess with the system perl which is updated using rpm or dpkg.
One question: how do you ssh in to someone's PC if they are behind IP masquerading and have a dynamically assigned IP address? I know there are ways to do it but I wonder if there is one that works out of the box on Fedora.
Informed choice: don't open unknown and unrequested attachments. Simple.
Yes, and by that logic any security vulnerability at all can be waved away: vulnerability in Firefox? don't view dodgy websites. The login box doesn't check passwords correctly? don't allow strangers to sit down at your PC and log in. All good advice, perhaps, but it doesn't remove the need to fix the problem.
In this case, it's well known that worms propagate by sending mail to people in your address book, so the dangerous attachment will probably come from someone you often get messages from. When you save it and view it in Nautilus on on the desktop, it will appear indistinguishable from a JPEG image.
Third, I'd give her a mailreader (Pegasus Mail) that doesn't allow saving executable-format attachments without a big scary "Could be a Virus" warning.
That's one way to do it, but it does fall into the trap of 'enumerating badness'. The mail reader cannot possibly know about all file formats that might be executable or dangerous. If your platform is sufficiently screwed up, then pretty much any file can be counted as executable (an old version of Windows Media Player would open a.wav sound file, but then finding that it was actually a Windows executable disguised as a.wav, would *execute* it without further warning).
I think it is also a good idea to fix the platform to reduce the set of files that are dangerous and increase the number that are safe. The Linux desktop actually does a pretty good job here. You can save an executable file and double-click it (assume for a moment you are a naive user who doesn't know what an executable is, which is at least 70% of users) - and this is perfectly safe, because it's won't be executed without the execute bit set on the file. Trying to 'open' it will do just that - open it, not run it - and perhaps it could even be configured to start up that hex editor you mentioned earlier.
In this case, making sure that.desktop files need to have the +x bit set to be executed would move them from the set of dangerous files to the set of safe ones. That is much more foolproof than relying on adding a check to every mail reader and web browser to know that.desktop files should not be saved.
Yeah, you save a file, and you choose to save it to the desktop.
If you think that's a big deal and only a moron would do it, then you should file bug reports against GNOME asking why it doesn't pop up a big warning box 'Do you really want to save this file?' and 'Do you really want to save it to the DESKTOP of all places?'. Because at the moment, these are common operations, ordinary users do them all the time, and there is nothing to inform an ordinary user that they might be dangerous.
What should happen, when you get an email attachment and you do not know what it is, is that you either ignore it, or if you have a certain morbid curiosity you maybe save it in/tmp and look at it in something that will treat it as random data (e.g., a hex editor) or use a file-magic utility to determine what kind of content it has in it.
Are you seriously saying that even 1% of users are able to use a hex editor?
I believe the problem may still apply when saving to other directories: the file browser can still show.desktop files with an icon and name of their choosing, and execute them when you double-click, even if they are not marked executable.
OK, so I exaggerated by saying 'there is no way'. Of course you could always pop up an xterm and view it with emacs, or better, od.
However I'm sure you agree that not every computer user can be expected to right-click and open with kwrite on every file they download, that many are not capable of doing so, and that even the unsophisticated users don't deserve to get pwned.
What is the way to open a file in GNOME? Why, to double-click it. We train users to double-click all the time. Suppose you were teaching your grandma how to use email and receive a file. I bet you would explain to her something like: right-click and choose to save the attachment, and then do you see it in the desktop? OK now double-click to open it...
The user is *not* explicitly executing the file! There is nothing at all explicit in the whole process.
What happens is that the user saves an attachment (which happens to be a.desktop file). On the user's desktop it appears with a filename of 'photograph.jpg' and an icon which is a thumbnail of a photograph. The user then double-clicks it.
Are you seriously saying that if you double-click an icon which shows a filename 'photograph.jpg' and a thumbnail, you have explicitly told the system to execute a command such as 'rm -r *'?
The vulnerability is in the way the desktop environment hides information from the user so you have no way (even if you are an experienced and responsible user) to avoid executing the malware. You get an attachment by mail, you just save it to look at it and see what it is (a one-click, and expected-safe operation) but when it appears on the desktop background, it's disguised as something else (the.desktop file can choose any icon and name it wants), and double-clicking to view the file in fact *executes* the code without asking you.
What should happen: you save the file; if you chose to save it to the desktop background it appears there, but because it's not marked executable it will not run when you double-click it. Instead the file contents open in a text editor, or some other fairly boring but safe action.
Yes, I do believe it should be safe to *open* any file from any source. If double-clicking a file to open it is unsafe, that needs to be fixed. Look at the security alerts for free software: a large proportion are things like 'a bug in the file decoding might allow an attacker to overwrite the stack by making a specially crafted PNG file'. These are treated as security holes and fixed, because it must be safe to merely *open* and view a PNG file (or whatever) from any source.
The idea that some files are 'bad files' which you should not even open to look at is a screwed-up view of the world that comes from Windows, where the OS and applications don't usually bother to make any distinction between opening and executing. On a sensible system, there is no reason to be afraid of using email and viewing attachments. I have absolutely no fear about saving any attachment from any source and opening it in emacs to view it. The desktop environment can and should provide the same safety.
To continue your analogy: the bug is that currently, with.desktop files, GNOME doesn't give you any way to see what it is apart from putting it in your mouth. Just as with any other kind of file, it should just display the contents for viewing, and not try to taste it unless the file is explicitly marked executable.
Your Nokia phone is not the only USB device that exists. Many models of Blackberry, for example, cannot charge using the standard USB current (at least not if switched on at the same time).
What you say is all true but it's not relevant to this particular problem, which is that *all* users, even sensible and cautious ones, can be easily tricked into running an executable because the user interface makes it look exactly like an ordinary file. You or I would also be vulnerable.
And BTW, I suggest you kiss her first, and fix the laptop afterwards.
Often the standard USB current isn't enough to charge a device, so you must install a driver which does nothing more than increase the USB power output.
Slashdot Mirror
Not really true. On the one hand, the government has the resources to wiretap your phone, for example, in a way that a random stranger cannot. On the other hand the government is constrained by various laws that restrict the information they can gather and use. For example in Europe at least data protection legislation restricts sharing of information between government departments, so even if the government as a whole knows several things about you it is unable to correlate them to reach conclusions. You can tell this data protection legislation is having a real effect because the British government wants to give itself the power to override the legislation.
Do you have any examples? I have installed all sorts of stuff in my NFS home directory and never had trouble with it. But then, I'm surprised that non-technical users are able to install Linux software at all. What are they getting?
Why do netbooks need a new name? It's a well-understood and generic term, just like biro or (in some countries) hoover. Let the lawyers deal with the lawyer-crap.
The usual answer is to write the core of the application in a relatively low-level language and add a scripting extension which can be used for less CPU-intensive, more rapidly-developed parts (often including the UI). The split between 'core' and 'extensions' varies but some examples are:
Firefox: core C++, UI and many extensions in Javascript.
Emacs: a small core in C, almost everything in Elisp.
Core in Java, scripting in Jython or another language that compiles to JVM bytecode (eg IBM Websphere)
Core in C#, scripting in IronPython, IronRuby, etc.
Core in C, scripting in Scheme (The Gimp's original Script-Fu, see also Guile)
There are other languages designed to be plugged into a C or C++ program, for example Lua and Tcl. You can even embed Perl though it's a little more complex.
Doesn't that depend on what language you speak?
It's a shame nobody has put the IWF list on Wikileaks by now...
Same here. I would never give money to the NSPCC but I'm happy to support Barnados. I hope we can get them to change their mind on the subject - or at least, recognize that political lobbying is not one of the functions of a children's charity.
I was pleased to see that my ISP, Zen Internet, is one of those refusing to bow to the IWF. I will continue to recommend them to friends and family as a sensible, human-run provider.
You are quite right that Javascript in PDFs is a lame idea, and executing it automatically is even lamer. However, even without Javascript or any other embedded programming language, the PDF viewing code (as a very popular program, presumably written in an unmanaged language, which needs to read a complex binary file format) still ought to be sandboxed to reduce the damage caused by future exploits.
And why exactly does Adobe Reader run with full permissions to all the user's files? Surely by now Adobe would have learned to run it in a sandbox. For example, the code that reads and renders the PDF could run in a separate process (a la IE8 or Google Chrome) and just send image data back to the main window.
More generally, the OS needs to make it completely easy to sandbox applications, so even the stupidest application developer can do it with little effort. Indeed, the default should be that it has no access to write files anywhere except those chosen by the user with the Save As box. I'm not holding my breath though...
I have found maintaining and updating a perl installation using rpm and yum to be considerably more reliable than the CPAN shell, which tends to trip over with build failures or mirror site failures... YMMV. I don't think it is practical however for every Mac across the globe to download files from the CPAN mirrors, including all the extra packages needed to get 'Build' and 'Build test' working, and trust that every Mac will build the package correctly without odd bugs creeping in. At least with distribution of binary packages you know what you're getting. Even Linux vendors (with the exception of Gentoo) ship pre-built packages for everything; I can't imagine Apple doing anything else.
I said 'Often the standard USB current isn't enough to charge', which is quite true. Often != always.
Never. My point is that having two different package managers operating on the same file is a bad idea. Each should keep to its own business and leave alone files managed by the other.
On a modern Linux distribution, it's actually okay to modify stuff that the vendor sends you, provided you do it using the same infrastructure as the vendor. For example, on an RPM-based system, you can easily build and install your own local RPM packages, with dependencies and all that, and they integrate nicely with the vendor-supplied ones. I wanted a newer version of the Perl LWP library than was in Fedora 10, so I grabbed the source RPM, updated it and built my own RPM package which I installed. Fedora then won't overwrite this unless they push out an even newer LWP release. Exactly the same can be done with dpkg-based systems.
If your vendor is incompetent, or you are paranoid and don't trust them, or some mixture of the two, then there may still be political reasons not to alter the vendor packages and instead put duplicate copies in a different directory. But nowadays there aren't always technical reasons why you shouldn't.
Why are Apple's updater and Perl's CPAN shell both trying to update the same file? If the file's there as part of the Apple OS then only the OS's package manager should touch it, and Perl should leave it alone (installing its own version in /usr/local if necessary). It's exactly the same on Linux distributions: the CPAN shell doesn't try to mess with the system perl which is updated using rpm or dpkg.
One question: how do you ssh in to someone's PC if they are behind IP masquerading and have a dynamically assigned IP address? I know there are ways to do it but I wonder if there is one that works out of the box on Fedora.
Yes, and by that logic any security vulnerability at all can be waved away: vulnerability in Firefox? don't view dodgy websites. The login box doesn't check passwords correctly? don't allow strangers to sit down at your PC and log in. All good advice, perhaps, but it doesn't remove the need to fix the problem.
In this case, it's well known that worms propagate by sending mail to people in your address book, so the dangerous attachment will probably come from someone you often get messages from. When you save it and view it in Nautilus on on the desktop, it will appear indistinguishable from a JPEG image.
That's one way to do it, but it does fall into the trap of 'enumerating badness'. The mail reader cannot possibly know about all file formats that might be executable or dangerous. If your platform is sufficiently screwed up, then pretty much any file can be counted as executable (an old version of Windows Media Player would open a .wav sound file, but then finding that it was actually a Windows executable disguised as a .wav, would *execute* it without further warning).
I think it is also a good idea to fix the platform to reduce the set of files that are dangerous and increase the number that are safe. The Linux desktop actually does a pretty good job here. You can save an executable file and double-click it (assume for a moment you are a naive user who doesn't know what an executable is, which is at least 70% of users) - and this is perfectly safe, because it's won't be executed without the execute bit set on the file. Trying to 'open' it will do just that - open it, not run it - and perhaps it could even be configured to start up that hex editor you mentioned earlier.
In this case, making sure that .desktop files need to have the +x bit set to be executed would move them from the set of dangerous files to the set of safe ones. That is much more foolproof than relying on adding a check to every mail reader and web browser to know that .desktop files should not be saved.
Yeah, you save a file, and you choose to save it to the desktop.
If you think that's a big deal and only a moron would do it, then you should file bug reports against GNOME asking why it doesn't pop up a big warning box 'Do you really want to save this file?' and 'Do you really want to save it to the DESKTOP of all places?'. Because at the moment, these are common operations, ordinary users do them all the time, and there is nothing to inform an ordinary user that they might be dangerous.
Are you seriously saying that even 1% of users are able to use a hex editor?
I believe the problem may still apply when saving to other directories: the file browser can still show .desktop files with an icon and name of their choosing, and execute them when you double-click, even if they are not marked executable.
OK, so I exaggerated by saying 'there is no way'. Of course you could always pop up an xterm and view it with emacs, or better, od.
However I'm sure you agree that not every computer user can be expected to right-click and open with kwrite on every file they download, that many are not capable of doing so, and that even the unsophisticated users don't deserve to get pwned.
What is the way to open a file in GNOME? Why, to double-click it. We train users to double-click all the time. Suppose you were teaching your grandma how to use email and receive a file. I bet you would explain to her something like: right-click and choose to save the attachment, and then do you see it in the desktop? OK now double-click to open it...
The user is *not* explicitly executing the file! There is nothing at all explicit in the whole process.
What happens is that the user saves an attachment (which happens to be a .desktop file). On the user's desktop it appears with a filename of 'photograph.jpg' and an icon which is a thumbnail of a photograph. The user then double-clicks it.
Are you seriously saying that if you double-click an icon which shows a filename 'photograph.jpg' and a thumbnail, you have explicitly told the system to execute a command such as 'rm -r *'?
The vulnerability is in the way the desktop environment hides information from the user so you have no way (even if you are an experienced and responsible user) to avoid executing the malware. You get an attachment by mail, you just save it to look at it and see what it is (a one-click, and expected-safe operation) but when it appears on the desktop background, it's disguised as something else (the .desktop file can choose any icon and name it wants), and double-clicking to view the file in fact *executes* the code without asking you.
What should happen: you save the file; if you chose to save it to the desktop background it appears there, but because it's not marked executable it will not run when you double-click it. Instead the file contents open in a text editor, or some other fairly boring but safe action.
Yes, I do believe it should be safe to *open* any file from any source. If double-clicking a file to open it is unsafe, that needs to be fixed. Look at the security alerts for free software: a large proportion are things like 'a bug in the file decoding might allow an attacker to overwrite the stack by making a specially crafted PNG file'. These are treated as security holes and fixed, because it must be safe to merely *open* and view a PNG file (or whatever) from any source.
The idea that some files are 'bad files' which you should not even open to look at is a screwed-up view of the world that comes from Windows, where the OS and applications don't usually bother to make any distinction between opening and executing. On a sensible system, there is no reason to be afraid of using email and viewing attachments. I have absolutely no fear about saving any attachment from any source and opening it in emacs to view it. The desktop environment can and should provide the same safety.
To continue your analogy: the bug is that currently, with .desktop files, GNOME doesn't give you any way to see what it is apart from putting it in your mouth. Just as with any other kind of file, it should just display the contents for viewing, and not try to taste it unless the file is explicitly marked executable.
Your Nokia phone is not the only USB device that exists. Many models of Blackberry, for example, cannot charge using the standard USB current (at least not if switched on at the same time).
What you say is all true but it's not relevant to this particular problem, which is that *all* users, even sensible and cautious ones, can be easily tricked into running an executable because the user interface makes it look exactly like an ordinary file. You or I would also be vulnerable.
And BTW, I suggest you kiss her first, and fix the laptop afterwards.
Often the standard USB current isn't enough to charge a device, so you must install a driver which does nothing more than increase the USB power output.