Weekly Edition
Return to the Security page
| |||||||||||||
Kretschmann: The Malware Problem (and a solution)
Amarok hacker Mark Kretschmann looks at the recent malware hidden in a GNOME screen saver. As he points out, it certainly isn't a GNOME-specific problem, as the same thing could happen to KDE and other projects. He and Ian Monroe came up with a way to help alleviate the problem by requiring public version control for Amarok scripts. "With a VCS [version control system], it's very easy to tell who inserted Malware, and when this person did this. This fact alone would provide some accountability, and I think it might prevent a good deal of attempts of messing around with the code. And even if it happened anyway, it would be trivial to revert the change, and we would just ban the person who did this from ever committing to this repository again."
(Log in to post comments)
Kretschmann: The Malware Problem (and a solution) Posted Dec 15, 2009 3:45 UTC (Tue) by gdt (subscriber, #6284) [Link] Using signing to provide accountability was the ActiveX strategy to limiting plugin malware. And that's worked well? Why would using version control to provide accountability work better?
The same solution looks works for linux kernel... Posted Dec 15, 2009 7:42 UTC (Tue) by khim (subscriber, #9252) [Link] "Given enough eyeballs, all bugs are shallow." Sing-offs works great if they are reviewed by thousands. They don't work if the choice is given to end-user. That being said there are a lot of sandboxes (like seccomp, VX32 or NativeClient) but the problem (as usual) is lack of standard. This is why make is still with us: SCons, CMake and others are better, but the sheer number of them makes switch more-or-less impossible. Still... the fact that so few projects are even trying to use proper sandboxing is not a good sign...
The same solution looks works for linux kernel... Posted Dec 15, 2009 10:53 UTC (Tue) by mpr22 (subscriber, #60784) [Link] The real problem with the others is that while they may be better (I've never tried them), any build process convoluted enough to need something better thanmake needs to be re-examined.
The same solution looks works for linux kernel... Posted Dec 15, 2009 15:52 UTC (Tue) by Kit (guest, #55925) [Link]
Generally people go with something other than make not because they need something more /powerful/, but because they need something that's more maintainable and usable.
The same solution looks works for linux kernel... Posted Dec 15, 2009 17:45 UTC (Tue) by nye (guest, #51576) [Link]
So they switch to CMake? I perceive a flaw in that plan...
The same solution looks works for linux kernel... Posted Dec 15, 2009 21:38 UTC (Tue) by cmccabe (guest, #60281) [Link]
I've used make, autogen / configure scripts, Cons (the ancestor of SCons), and CMake. Overall, CMake was the best of them. It doesn't deserve your snark.
Only one caveat: I never tried to do a distriubted build with CMake.
distributed cmake Posted Dec 15, 2009 22:32 UTC (Tue) by xaoc (guest, #54140) [Link]
CMake is made for effortless distributed builds. Make on the other hand is a bit tricky when there are recursive invocation.
A 60 MB project I converted to cmake now builds in 1-2 minutes on 16 cores with ~50 threads. It used to take 30 min before.
distributed cmake Posted Dec 18, 2009 10:34 UTC (Fri) by cortana (subscriber, #24596) [Link]
Out of interest, did it use make recursively?
distributed cmake Posted Jan 11, 2010 11:46 UTC (Mon) by cmccabe (guest, #60281) [Link]
Yeah, it is pretty nice how CMake provides effortless parallelization via "make -j". However, by "distributed build" I meant a build that happens on multiple computers, caches build results remotely, etc.
I know that SCons has distributed functionality built-in. I'm not sure how you go about it with CMake. I guess distcc and friends, but how well does that work out in practice?
The same solution looks works for linux kernel... Posted Dec 16, 2009 9:47 UTC (Wed) by mark.kretschmann (guest, #62528) [Link]
CMake is fantastic. We at KDE are very happy with it.
It's fully FOSS, very well maintained, and allows doing cross-platform development very easily. I really recommend looking at it.
The same solution looks works for linux kernel... Posted Dec 16, 2009 11:16 UTC (Wed) by nye (guest, #51576) [Link]
CMake stressed me out so badly I broke a Model M keyboard. I despise it more than words could ever express.
The same solution looks works for linux kernel... Posted Dec 16, 2009 14:25 UTC (Wed) by jengelh (subscriber, #33263) [Link]
cmake (and others) made a fatal flaw. Example:
./configure CFLAGS="-O2 -g" libfoo_CFLAGS="-I$HOME/libfoo/include -D_OMG" libfoo_LIBS="-L$HOME/libfoo/libs -lfoo -lbar"
Guess what it's for cmake? SOL.
cmake -DCMAKE_CXX_COMPILER=/usr/bin/g++ -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_FLAGS_RELEASE="-O2 -g" -DLIBFOO_INCLUDE_DIR="$HOME/libfoo/include" -DLIBFOO_LIBRARY="$HOME/libfoo/libfoo.so"
and the rest (-D_OMG -lbar) I would not know offhand how to encode. That is what puts the nail into the coffin for cmake.
The same solution looks works for linux kernel... Posted Dec 16, 2009 15:47 UTC (Wed) by mark.kretschmann (guest, #62528) [Link]
Sou you're dismissing CMake just because the syntax is different from Automake's?
I can see where your "fatal flaw" is. Hint: It's not in CMake ;)
PS:
The same solution looks works for linux kernel... Posted Dec 18, 2009 21:37 UTC (Fri) by jengelh (subscriber, #33263) [Link]
Yes indeed. Well at least I wanted to express that it is perhaps this different syntax that causes not more people to use it.
The same solution looks works for linux kernel... Posted Dec 16, 2009 22:50 UTC (Wed) by mikov (subscriber, #33179) [Link]
I share your sentiment. I don't exactly despise it, but I think it is a completely braindead idea (a program that generates platform dependent makefiles - WTF - why not just perform the build!), and its adoption is due to the mostly superficial gains it offers compared to make.
SCons on the other hand is excellent. I use it for all of my C projects lately and I highly recommend it. (I am not a Python programmer at that). I really could not imagine why anyone would use CMake when SCons is available.
The same solution looks works for linux kernel... Posted Dec 17, 2009 1:54 UTC (Thu) by pynm0001 (guest, #18379) [Link]
You mentioned that CMake generates makefiles instead of just performing
the build, but that's not uncommon in program design.
For example, gcc generates platform-dependent assembly which it then hands
It is annoying when CMake and make have to perform some work twice but
The same solution looks works for linux kernel... Posted Dec 17, 2009 8:42 UTC (Thu) by boudewijn (subscriber, #14185) [Link] Have to go over this again? For the short of memory: KDE started with scons for KDE 4.0. Scons could not build kdelibs, and the scons developers were not interested in cooperating with KDE to make scons good enough. Had KDE continued to use scons, it would have had to maintain a complete fork of it. CMake was nearly good enough and the CMake developers were really interested and active in helping KDE build using CMake. So, maybe that will help your imagination a bit and make you understand why one huge project, at least, has chosen to use CMake.
The same solution looks works for linux kernel... Posted Dec 17, 2009 19:12 UTC (Thu) by mikov (subscriber, #33179) [Link]
I wasn't asking about KDE, bit since you raised the question... Certainly I have heard this before, but yet again there is a complete lack of explanation as to in what ways SCons was so badly deficient.
Having studied both SCons and CMake, and having done some pretty complicated builds with SCons, I find this puzzling. Although CMake is not terrible, it is inferior as a concept and quite possibly as an implementation.
KDE may be a huge project, but it is not magic - it still boils down to the same old compiling of C++ source files, and I am pretty sure you could do that even with a Bash script, let alone with SCons, not to mention Python.
So, I suspect the truth is that KDE wanted to use SCons in some KDE-specific way, which the SCons developers weren't interested in accommodating. That is fine, it is a free world, however nobody has so far explained what exactly the problem was.
That is, if you want to persuade me that CMake is superior, I welcome it, but instead of anecdotes, please tell me why.
In the meantime, here is the high level view of why I think SCons is superior:
The only advantage CMake could have had is syntax optimized for its purpose (Python can be more verbose that Make for example), but alas its designers have missed this opportunity.
CMake Posted Dec 17, 2009 20:08 UTC (Thu) by sbishop (guest, #33061) [Link] It doesn't rely on external make.You keep harping on this. Do you realize that it's considered a feature? CMake targets far more than just make(1). It can also create Xcode and Visual Studio project files, for instance. Perhaps that's a flawed idea. But the fact that you haven't acknowledged it makes me think that you don't know what you're talking about.
CMake Posted Dec 17, 2009 21:55 UTC (Thu) by mikov (subscriber, #33179) [Link]
Exporting a project file for an IDE is a nice feature, but is completely orthogonal to building the project.
Relying on different incompatible and differently buggy external tools to do the build is a stupid idea. If you think that it isn't why don't you explain why? What advantages does it bring? Additional complexity? Additional tool dependencies? Slower builds? Those are not advantages.
CMake Posted Dec 17, 2009 22:43 UTC (Thu) by sbishop (guest, #33061) [Link]
If some poor, ignorant fool is using Xcode or Visual Studio without SCons,
how do you think the IDE's default build tool knows what to build?
I think that my point and boudewijn's is the same. You are making very
CMake Posted Dec 18, 2009 6:06 UTC (Fri) by mikov (subscriber, #33179) [Link]
Please, don't attempt to guess what other people know - you might get unpleasantly surprised ;-)
So far both have you have failed to make a point beyond repeating that apparently you like CMake.
Let me try to explain one of CMake's problems - a problem which I thought was apparent (which shows again that one should never attempt to guess what other people know). By relying on separate and different 3rd party make tools for its core functionality, it is ultimately limited to a subset of what any of them can do in a portable build.
I suspect that CMake went that way because it tried improving Automake/Autoconf, instead of looking how to actually _do_ a portable build. That doesn't mean it is unusable - Automake is also usable - but it is a dead end. Also, trying to debug the intersection of CMake and all possible make tools must be fun.
Again, exporting an IDE project file is a nice feature, but it has nothing whatsoever to do with building the software.
CMake Posted Dec 18, 2009 16:59 UTC (Fri) by sbishop (guest, #33061) [Link] I like CMake? That's news to me. If you were to reread my comments carefully, this would not come as a surprise to you. Look. I understand that you want to argue with someone about the superiority of SCons over CMake. So far no one has taken the bait, but have simply pointed out that the bait you have provided indicates that you are not actually interested in the facts. Consider this: So, I suspect the truth is that KDE wanted to use SCons in some KDE-specific way, which the SCons developers weren't interested in accommodating. That is fine, it is a free world, however nobody has so far explained what exactly the problem was. (emphasis mine) The reasons for KDE choosing CMake over SCons are readily available and well-documented. But you prefer your suspicions over the facts. That's fine. I will not bother you further.
CMake Posted Dec 19, 2009 1:24 UTC (Sat) by mikov (subscriber, #33179) [Link]
I am interested in facts, if only you had presented any... Even now you insist that the reasons for KDE choosing CMake over SCons are readily available, but fail to mention where.
You have not posted a single fact or a reference, just unsubstantiated opinions (not to mention vague insults): that CMake's disadvantages are somehow features, and I don't know what I am talking about.
This is not going to help you win any technical arguments.
CMake Posted Dec 25, 2009 3:33 UTC (Fri) by ccurtis (guest, #49713) [Link]
LMGTFY? http://lwn.net/Articles/188693/
CMake Posted Dec 25, 2009 3:57 UTC (Fri) by mikov (subscriber, #33179) [Link]
Please, don't post if you can't be bothered to contribute meaningfully. Believe it or not other people can read and use Google too.
I am well familiar with the linked article and it doesn't explain any specific SCons problems. It literally contains only one sentence:
"There were major problems building KDE on non-Linux platforms with SCons (e.g. on OS X); in general they felt it did not yet have a mature configuration system."
Did you just skim through the article or do you really believe that this sentence alone is enough technical justification against SCons?
The same solution looks works for linux kernel... Posted Dec 17, 2009 21:05 UTC (Thu) by boudewijn (subscriber, #14185) [Link] "I wasn't asking about KDE, bit since you raised the question... Certainly I have heard this before, but yet again there is a complete lack of explanation as to in what ways SCons was so badly deficient." If you, four years after the decision was made, want to know why that decision was made, don't wait for someone to turn up and educate you with explanations, but go and read the mailing lists, the articles published on LWN (which, iirc, have links to the mailing list postings) and so on. I doubt the complicated builds you have done with scons were done four years ago; I find building a simple app with scons on windows or OSX -- or even Linux -- pretty hard even today. It doesn't even reliably check the dependencies! I also really doubt they were as complicated as KDE. In fact, I have never seen a project of any real complexity (5 platforms, > 1000 kloc, dozens of dependencies, etc.) that uses scons. Show me one: then show me a project or a family of projects that is ten times as big and complicated that uses scons. "So, I suspect the truth is that KDE wanted to use SCons in some KDE- accommodating. That is fine, it is a free world, however nobody has so far explained what exactly the problem was." That's your suspicion: it is up to you to prove that you are actually right, not for anyone else to prove that you are wrong.
The same solution looks works for linux kernel... Posted Dec 17, 2009 22:07 UTC (Thu) by mikov (subscriber, #33179) [Link]
You seem to be taking this way too personally.
Anyway, you still haven't even made a hint of a technical explanation of why CMake is superior, or why it was chosen by KDE. That makes me think that you don't know. You haven't addressed the advantages of SCons that I listed either. Which probably means that you have just accepted the KDE decision without ever understanding it. That is fine, but why go attacking people who have made their choices based on real technical motivation?
I am not going to go dig through the KDE mailing archives for something that you raised and for a point that _you_ want to make. If you know why SCons is allegedly inferior, please show it hard technical data. "It can't do this, and that, it is x times slower, it has these conceptual problems, etc, etc."
You are right that I don't know how good or bad SCons was four years ago. But I don't care. I am using it _today_. My recommendation for SCons, to which you reacted, was based on SCons _now_.
You seem to think that the state of SCons four years ago, in relation to CMake, matters now. You supposedly know why. You brought this up. So, please explain.
The same solution looks works for linux kernel... Posted Dec 18, 2009 20:45 UTC (Fri) by aleXXX (subscriber, #2742) [Link]
Ok. At Akademy 2005 (OMG, so long ago ?) it was decided to switch away
from autotools to something else, and that something else was scons.
After months of development, early 2006, we, in KDE didn't have one
The problems we had with scons...
-there was no standard way to do configure checks. The configure checks
-it was not able to build tools during the build, which were necessary
-the Scons developers did not cooperate too good. We (in KDE) need a high
-support for Windows (or was it OSX, or both ?) was not good enough. I
Beside that, personally, I consider it an advantage that with CMake you
Also, I heard, that scons would be quite slow with bigger projects,
Alex
The same solution looks works for linux kernel... Posted Dec 19, 2009 0:59 UTC (Sat) by mikov (subscriber, #33179) [Link]
Thanks! That was a very informative explanation and it is much appreciated. I just re-read the old LWN article on the subject (which in fact had prompted me to try CMake initially), and there are not much details there, except the configure checks. You certainly filled in the blanks.
Presented with these facts, I don't dispute that CMake was the right choice for KDE four years ago, and it could very well be better today if that choice had to be made again. I especially agree that the flexibility of Python could present problems in a huge distributed project, although that could perhaps be addresses with a policy (e.g. any custom Python has to be in the dedicated place - "site_scons/" - and it has to be reviewed approved by the build maintainer).
I have to agree that SCons is not universally superior, although I believe it is "conceptually" cleaner and more powerful. But that doesn't mean a thing if it isn't the right choice for your project :-)
I think that some if not all of the problems you mentioned have been resolved in the meantime:
- I use both configure checks and build tools for later use in the same build without problems. SCons implicitly adds the build tool as a dependency to each source that it is used for, so this is something that seems well supported and well designed. The configure checks also participate in the dependency tracking, so it works out quite well.
- I have to admit that I haven't used SCons in Windows, so I can't vouch for it. Although from knowing how SCons works (I have gotten familiar with its sources in the course of using it), it ought to be fine. But who knows...
- OSX support is a more tricky issue. I personally don't understand it well, but at least there are serious discussions in SCons about it: http://scons.org/wiki/Containers
- About the performance. I believe that might be slightly misleading. A monolithic build may appear slower than a recursive one, but they are not really comparable. SCons shouldn't be doing anything more than Make; in fact it is usually doing less because it has better dependency tracking. From my personal experience it has sped up my builds, and I know of at least one company where a big project's build was sped up considerably after they switched to SCons. But admittedly this is anecdotal evidence that doesn't mean much. SCons also tends to be memory hungry, which could be slowing it down (I don't know that it does though).
SCons can be tricky to learn to use at its full power. It does have an excellent user guide and man page (certainly better than CMake), but those are not always sufficient because it is quite complex and sometimes works in subtle non-obvious ways.
Compared to CMake which generates different (and hardly readable) Makefiles on different platforms, I think it easier to debug build problems.
Overall I find its ideology amazing elegant, clean and powerful and intuitive to use, although clearly the latter is very subjective.
The same solution looks works for linux kernel... Posted Dec 15, 2009 10:55 UTC (Tue) by dgm (subscriber, #49227) [Link]
Only a guess, but maybe the problem with seccomp, VX32 or NativeClient is that they are very good solutions for a narrow scope of problems, and the lack of portability.
What's lacking is a good generalized way for applications to provide services to additional (potentially hostile) code, in a tightly controlled way.
If you think about it, that's exactly what the kernel does, so what we need is an kernel extension that allows applications to act as kernels themselves (a higher level kernel, if you want). Not only hardware virtualization or x86 specific, like VX32 or NativeClient, and less stringent than seccomp.
Additionally, this kind of extension should be incorporated in as many UNIX-like kernels as possible.
The same solution looks works for linux kernel... Posted Dec 24, 2009 17:10 UTC (Thu) by glup (guest, #62317) [Link]
FreeBSD+Jail?
Kretschmann: The Malware Problem (and a solution) Posted Dec 15, 2009 10:39 UTC (Tue) by pebolle (guest, #35204) [Link]
> Why would using version control to provide accountability work better?
Hard to say, since the post is rather light on details, but it seems safe to assume it wouldn't.
The author of that blog post points to a specification called ghns (ghns.freedesktop.org), since that would be an important step in enforcing this idea. ghns actually looks almost like some toy specification (though they claim it is used by some third parties). I couldn't find anything about the security considerations of that specification in its documentation or its examples.
Anyhow, if I understand this blog post correctly, the author is associated with a media player that allows scripts (that I guess can provide some non-essential features). Those scripts are given unrestricted access to, well, about anything accessible to the user running that media player. Neither the author nor other members of that project are able or willing to actually review the code for these scripts. (At least he implies they aren't.) Somehow this proposal should even solve the obvious issues with their scriptable media player. I'm not yet convinced ...
Kretschmann: The Malware Problem (and a solution) Posted Dec 16, 2009 9:54 UTC (Wed) by mark.kretschmann (guest, #62528) [Link]
Hello, here's "the author of that blog post" speaking, who also happens to be "associated with a media player".
And "you" should read the article again, but more carefully this time. You did get a few facts wrong, and then you managed to misunderstand it all too.
Congratulations :)
Kretschmann: The Malware Problem (and a solution) Posted Dec 16, 2009 10:06 UTC (Wed) by pebolle (guest, #35204) [Link]
I would appreciate it if you'd just tell me (and other readers of this thread) which facts I got wrong and how I also managed to misunderstand it all.
Kretschmann: The Malware Problem (and a solution) Posted Dec 17, 2009 8:40 UTC (Thu) by gdt (subscriber, #6284) [Link] I read your blog posting prior to my comment. Accountability is not a silver bullet. You can have the name, address, photograph of a malware author -- you could even have the GNOME Internet Police arrest them -- but you are still stuck with the consequences of their program. You also suggest having a canonical source of reviewed plugins. Not a poor idea, but it has little to do with source control systems beyond requiring one as a small element of the implementation. The reviewer support system is likely to be more difficult.
Kretschmann: The Malware Problem (and a solution) Posted Dec 15, 2009 11:38 UTC (Tue) by tialaramex (subscriber, #21167) [Link]
To be fair the biggest problem with ActiveX was with controls that were never intended to run in a browser. It was much too easy for a widget intended for native software to end up running in the context of a web page, whereupon the bugs (which had seemed harmless to the people using it in a full-blown application) became security holes.
If Microsoft had re-used most of the technology but with some additional process to make a control into a browser plugin, there'd be many times less ActiveX controls in web pages, thus a much smaller security exposure, and right now ActiveX might have a reputation no worse than Netscape's plugin API. Of course then Microsoft couldn't have announced that they had a bazillion plugins on day one.
Screensavers do seem like a good application for SELinux - usually the problem is "I don't know what my application may need to do, so I can't create a policy" but with screensavers you could just insist that all the ones available from a site like Gnome Look must live with a very simple and highly restrictive policy, file access only to specially labelled files, no network access, no new processes etc. If someone wants to build a screensaver that downloads random 4chan images or de-fragments your disk then Gnome Look's not the place for that.
Right now it seems like the lesson is (as expected) don't run executable code uploaded to the Internet by random people you know nothing about.
Sandboxing by default Posted Dec 15, 2009 10:30 UTC (Tue) by dion (subscriber, #2764) [Link]
As people who are accustomed to downloading and running any random file they can start using Linux this problem will grow and keep growing until a proper, general solution is found.
Educating end-users about security is not any sort of solution at all, so the user must not be involved in security decisions.
Any user-writeable executable ought to run in a very limited sandbox, unless a trusted parent process has explicitly allowed the access.
Expecting every single application to implement sandboxing for the user-provided plugins is highly unreasonable, so a framework to make it simple is certainly needed.
Perhaps all untrusted code could all be run in the same environment from the kernel point of view where the only access to the outside world is via already open files (and sockets) and perhaps some shared memory?
In such a limited environment the standard libc could be replaced to provide unmodified, but untrusted programs with the illusion that they still run normally, the sandboxed system calls could then be piped out to the wrapper process where more detailed limitations could be applied.
The trick of designing a default sandbox is that it must be restrictive enough to not allow any real damage, but lose enough to allow some useful work, I'd suggest something like:
At no point should a user be asked if the untrusted program is allowed to do certain things, because the answer will always be "yes, bugger off", any unsafe operations by an untrusted process should be met with a SIGKILL from the kernel or the wrapper process.
The only way to make sandboxing work at all is to make it work well enough that end users are *NEVER* asked to download random .deb files, so it might not happen soon...
Sandboxing by default Posted Dec 15, 2009 10:50 UTC (Tue) by mpr22 (subscriber, #60784) [Link] Where is the boundary between trusted and untrusted code? How much filesystem metadata support is this going to need?
Sandboxing by default Posted Dec 15, 2009 11:26 UTC (Tue) by dion (subscriber, #2764) [Link]
Yes that's the trick isn't it?
I'd probably make any files not owned by root be marked as untrusted, any file owned by the user is certainly suspect.
Sandboxing by default Posted Dec 15, 2009 14:19 UTC (Tue) by mpr22 (subscriber, #60784) [Link]
The first issue I see with that is that most of the things that are designed to run setuid not-root are not designed to play in a sandbox. The second is that it encourages people getting into developing software in a compiled-to-native-code language to do all their work as root.
Sandboxing by default Posted Dec 15, 2009 10:51 UTC (Tue) by anselm (subscriber, #2796) [Link] You're essentially describing the sandboxing model that Tcl/Tk introduced (for Tcl scripts) more than 10 years ago. It seems that once more John Ousterhout was way ahead of his time.
Sandboxing by default Posted Dec 15, 2009 11:33 UTC (Tue) by dion (subscriber, #2764) [Link]
Hey, I made no claim to be original:)
The problem with sandboxing native code compared to tcl is that the level of abstraction is so much lower and the expectation of performance is much higher, so effective sandboxing demands new chunkier interfaces (like "write the screensaver frames to this bit of shared memory") or elaborate frameworks (like a separate X server per. untrusted process)
There is no reason that Googles Native Client can't provide as a secure environment as Java or Mono, because like the VMs it forces the code to use a specific high-level API that's easily sandboxable.
Making existing code run in sandboxes is very hard, so perhaps we're better of never allowing any untrusted legacy code at all?
Sandboxing by default Posted Dec 15, 2009 12:41 UTC (Tue) by pcampe (guest, #28223) [Link]
You are asking for a SELinux policy indeed.
Look at this, where Dan Walsh deploy a sandbox for grid computing:
Sandboxing by default Posted Dec 15, 2009 15:07 UTC (Tue) by dbruce (subscriber, #57948) [Link]
"Educating end-users about security is not any sort of solution at all, so the user must not be involved in security decisions."
The problem is that these uneducated end-users are the owners of their computers, at least for the home, so there is no getting around their involvement. There needs to be a sane way for people to manage their machines. It all sounds great to consider ways to lock this down, but it won't help if it upsets the user too much. They will either respond with "bugger off, I'm just going to run as root", or "bugger off, Linux sucks, I'm going back to Windows".
The one part that is right IMHO is that we can steer people towards always using software from the distro's official repository.
Sandboxing by default Posted Dec 15, 2009 17:45 UTC (Tue) by muwlgr (guest, #35359) [Link]
Some users are better to stay with Windows from the start.
No need for them to go to Linux and back. Linux is not a Dollar to be liked by everyone :>
Sandboxing by default Posted Dec 15, 2009 20:59 UTC (Tue) by tzafrir (subscriber, #11501) [Link]
Now grab my great new screen ssver that introduces a whole new method to showing a slide show. All you have to do is point it to a directory of images for the slide show. Optionally define slide time out and transition effect.
Alternatively it can grab screen shots from Flickr.
Grab it now at http://192.0.32.10/~tzafrir/screen-savers/
Kretschmann: The Malware Problem (and a solution) Posted Dec 15, 2009 11:17 UTC (Tue) by NAR (subscriber, #1313) [Link]
If I understood correctly, the malware was in a .deb package, so it doesn't really matter what kind of sandbox is around the application, because the preinstall/postinstall/"I don't know how it's called in .deb" scripts run as root anyway and the system gets hacked there.
Kretschmann: The Malware Problem (and a solution) Posted Dec 15, 2009 17:54 UTC (Tue) by TomMD (guest, #56998) [Link]
Yeah, that paragraph is non sequitur what with it talking about a .deb and end users then moving to protecting developers from malicious commits on the code repo. It doesn't help that the main link (for Mark Kretschmann comments) is broken right now.
Kretschmann: The Malware Problem (and a solution) Posted Dec 15, 2009 18:03 UTC (Tue) by Trelane (subscriber, #56877) [Link]
There has to be a way to modify the system to secure it. The first thought might be distinguishing between distro-shipped and non-distro-shipped code, through signatures. Of course, being Linux, the end-user must have a say in who is a trusted party, which is a weak point. However, there's no reason you can't provide this line of defense. There may well be other methods, such as distinguishing between classes of debs (e.g. themes vs a server vs a client package) which determines what places they'd be allowed to scribble. And of course, there's no reason a themes package has to be a deb either.
Kretschmann: The Malware Problem (and a solution) Posted Dec 17, 2009 9:55 UTC (Thu) by tzafrir (subscriber, #11501) [Link]
You mean: allowing Verisign to decide who I should trust is better?
Or allowing Apple to extort a tax from developers to provide me applications for a "store" which is the only way to install application on my system is a better way?
Kretschmann: The Malware Problem (and a solution) Posted Dec 16, 2009 9:34 UTC (Wed) by mark.kretschmann (guest, #62528) [Link]
Sorry about that. We had a complicated server move going on yesterday (from one data center to another), which caused some temporary downtime. I didn't expect my article to end up here, so this was bad timing, but meh: Murphy's Law...
The site (and blog) is up again :)
Kretschmann: The Malware Problem (and a solution) Posted Dec 15, 2009 23:21 UTC (Tue) by zooko (subscriber, #2589) [Link]
The fundamental problem is that the screen saver runs with all the authority of the user. All
solutions which don't fix that are bad solutions which cause other damage but which won't fix the problem.
This implies that it probably can't be fixed by the Gnome folks -- it will probably require help from
Kretschmann: The Malware Problem (and a solution) Posted Dec 16, 2009 14:32 UTC (Wed) by SEMW (guest, #52697) [Link]
> The fundamental problem is that the screen saver runs with all the authority of the user.
In this case, surely the problem of 'the screensaver running with all the authority of the user' rather pales next to the problem of the installation script (as part of a deb) running with all the authority of root.
The solutions to *that* problem (e.g. gnome-look mandating that themes/screensavers etc. be published as, say, tar.gz rather than deb, and giving instructions for installing them manually; or for a deeper solution, rearchitecting dpkg to be able to run without root privileges to install things for the current user only, and educating users that things like screensavers should be installed in that mode) reduce it to the problem you identify.
Kretschmann: The Malware Problem (and a solution) Posted Dec 16, 2009 15:38 UTC (Wed) by dps (subscriber, #5725) [Link]
A honest screen saver should be happy with
- The ability to connect to the X server - The ability to grab the X server - The ability to manipulates its own windows - Read only access to a few basic root window properties - The ability to verify a user name and password (for screen savers that implement that feature). - Access to a few specific files.
I *want* xlock to grab my server so that no evil clients can connect and arrange to intercept my password when I get back and unlock the display.
This looks like something security labels should be labels to manage, especially is you can use XACE. The only problem is ensuring your box is usable in selinux enforcement mode. I am not quite there yet.
There is not really any way of saving windows users that always use accounts with admin privileges. You do not need security exploits because those people also say "yes, please execute this" almost all the time.
Duncan (-:
Kretschmann: The Malware Problem (and a solution) Posted Dec 17, 2009 7:54 UTC (Thu) by tialaramex (subscriber, #21167) [Link]
A sane design doesn't put most of the stuff on your list into the "gee whiz" screen drawing code, the part people are interested in replacing and which Xscreensaver calls a "hack".
Xscreensaver's hacks could in general run with almost no privileges. They need only permission to scribble on an X window, presumably via a socket. They don't (in general) need to access disk, they don't need access to the network, and they certainly don't need the user's login credentials.
But here we are, almost in 2010 and people are talking about how the code that draws an amusing randomly generated snowman on their PC when they're at lunch needs to know their password. That's pretty sad.
Kretschmann: The Malware Problem (and a solution) Posted Dec 18, 2009 1:43 UTC (Fri) by nix (subscriber, #2304) [Link]
electricsheep, to give a random example of a seriously cool screensaver, wants to access the network and read/write to part of the filesystem (as a cache). So would lots of other screensavers that make your machine part of a distributed system while the screensaver is running.
|
|||||||||||||