for example you reserve some combinations of parameters for future use...
Using 'reserved' parameters in an API is bad design, IMO. API interface shall be 100% transparent.
It would be better, when new parameters are required for a finction call/method, to extend the API with a new function, which does the same as the older one but with the extra tweaks permitted by the new parameters ( and if I remember win32 API, there are several cases of this, meaning that someone in M$oft agrees with me [should I start to worry:-? ]).
However, you could not use this as a way to, say, discretely intercept logins and passwords, transfer account balances, read someone's database, or what have you since all of that requires you to intercept things and still provide the user with acceptable responses (at least if you wish to avoid detection for more than a couple runs).
I could. Almost in exactly the same way I would do adding a backdoor to an open-source program. From my evil code at the beginning I can read files and databases, redirect/duplicate network trafic, and so on. Truly, I might not be able to interact with the original code (not without some clever trick, anyway), but this is not needed to steal secrets: a password is not generated inside the program: it comes from outside (and I can intercept that) and often go outside(and I can intercept that).
On the other hand, cleverness shall be applied also to place a backdoor in open source programs: or do you think that something like:
gets(password);
send(socket, password, strlen(password))
would not be spotted the same second in which it is submitted in the CVS of some open source program?
but that same person is unlikely to have the skill or the patience to make a truly undetectable trojan in a binary/proprietary package.
It takes much less than you seem to think:
rename the target binary 'program' as 'program.lib'
Make a C program that first does the evil you want to do, then execv program.lib
Compile your program and put it instead of the original program executable.
Of course there are ways to detect this simple trick. By inspection, checksum, whatever. The same ways that can be used to detect trojans in open source programs. So, you see, there is no difference security-wise.
To proper verify a signed source package, you need a secure way to obtain the developer public key.
E.g. either from him, or fronm someone you trust that got it from him, or from someone that got it from someone trustable that got it from him... (of course, the longer the chain is, the weaker it becomes).
In the worse case, you get the key from the Net, then get it from another (not mirror) place, and compare. Do it again with a third place. Now you got some security: not much, but some.
Not that I do any of this. But I have nothing to loose if they get at my home PC.
Obviously there are exceptions - that's how this occurred - unless of course you are suggesting that the maintainer of this package was complicit in adding the trojan.
If this troian got inside like the others (OpenSSH and Bind, IIRC), it was _not_ a patch submitted to the project. Simply, somebody rooted the FTP server and substitute the official tarball with the troyanize one.
In other words, the weak point that was exploited was not that anybody can contribute to an open source project ( which is not a weakness at all IMO) but that source tarballs are hosted on insufficiently protected FTP servers.
There are counter-measures against this weakness. As long as distros use them (and I hope they do), it is unlikely that one of these trojans will slip into an officia CD.
You're right. But if someone that has never seen Star Wars (e.g. someone that doesn't like SF) come out with a novel in which a young fellow from a backwater place challenge an evil empire, saving a princess in the process, I bet Lucas's lawyers will go after him in no time.
Thinking of it, the only thing that saves Linus from a "Cease and Desist" letter by LucasFilm is the lack of a princess to save.
Well, not CPU-wise or RAM-wise, at least. Take the
Sharp Zaurus: 200MHz ARM processor, 64 MB ram + 16MB ROM,TFT LCD 3.5" with 240x320 pixel, 65,536 colors. And if you have enough money, you can add to it an IBM 1GB micro-drive.
I'm dreaming to use it as a substitute for the 5-years-old laptop I currently carry around : Pentium 150 MHz, 80 MB, 1.4 GB, 10" DSCN LCD 800x600. It would be sweet to have a full-featured PC in your pocket(almost).
What this is probably aiming for is the same sort of user as XP, i.e. one that doesn't want to know about 'root' he wants things to 'just work'.
Unfortunately, they often get things that 'just break', too.
I believe the right thing is what some distro already does : when a normal user attempts privileged operations, like configuring the machine, he is asked for root password. This is easier than becoming root and more secure than having an everybody-is-root environment.
Example: hardware vendors should all work together and cooperate. There should be only one single kind of CD drive, one kind of each size of monitor, one kind of CPU, etc.
The Bazzar seems to work there quite well. Look at hardware prices
Right. Except that CD drives all uses the same data interface, power connection etc... Same for the monitors.
I would like to see the same on Linux: I don't care for a single desktop: I _do_ care for a standard desktop infrastructure.
Places like freedesktop.org and xml.openoffice.org
seem to point to the right direction: but it will be a slow going, I think.
The problem probably was that Konqueror and KMail shared the same MIME info. It may make sense that when you click on an icon of a.exe, konqueror starts Wine to run it. It doesn't in the case of Kmail. Kmail should at least be aware of which 'helpers' (wine or python or whatever) actually run arbitrary code and offer a warning/confirmation window.
The whole point of e-mail viruses is that Windows blurs the distintion between data and programs, in the name of usert-friendlyness (showing that too much friendship is dangerous). Linux should try instead to implant the distinction between 'passive contents' and 'active programs' in all its users. In this respect, the idea of having all 'interpreters' program, including perl, python and whatsnot, to rispect the 'executable bit' of files is not bad, although I believe it will never happen now that distros are after to desktop users.
Most of us live in a democratic society. Democracy has historical won over the hierarchical societies - for a reason.
The reason has to to with ethics, human nature and emotions. Not with logic.
Most of us work in some company,and companies have
a hierarchical structure - for a reason: it is more efficient and, in theory, it is easy to spot where the fault is (in practice it is not, because power and responsibility are not coherently assigned : some have power, others get the blame when things go wrong).
I had the same thought ('if it only checks the access to the system calls, how can I prevent/grant the access to single files/directories/port numbers?).
Then I went to read the actual thing here,
and I found that it also checks for syscall arguments, including some sort of pattern-matching
(you can even change dinamically the system call arguments, making a sort of chroot-on-the-fly).
It looks like a promising idea. My only concerns are:
1 - performances
2 - setting up a policy file requires a good knowlwedge of system calls, and not many programmers (not to speak of users or sysadmins) have that. The interactive policy setup helps a little, but it is _you_ that have to say 'yes' or 'no'.
This method needs to be supported by packagers: when you upgrade a packet (binary or source) for a system that supports this method, the package should contain a new policy file.
Ok, this lead to the question: what if the policy file is compromised? Even so, spotting an unneeded privilege in the policy file should be easier than spotting some rogue code in a large program.
since its primary duty is towards its shareholders
As someone else pointed out in another thread, _this_ it why the system is broken.
Their primary duty should be toward their _customers_ (you know, those peope that give them money in exchange of some kind of product/service). Only once customers get a fair deal for their money ( where fair is admittedly a greatly subjective term, but broad boundaries are still better than nothing), then they should be free to care for their shareholders.
I've read all the fundation saga (5 or 6 books - they should update the definition of trilogy in dicionaries as "three or more books") and don't remember such a think. But it could be me.
I _do_ remember however that in
Larry Niven universe there is an expanding black hole in the center of our galaxy, which will destroy all of it in the next hundred thousand years or so.This is wy the Pierson's Puppeteers ( a very "prudent" alien race) decide to leave immediately this galaxy.
Instead ot talking about time, let's talk abut money.
Someone who patents an idea, shall document how much
they spent (labour, materials, etc ). Add to that a standard 30% profit.
Everybody can use the patented idea, by paying a share of that cost. More people/companies use the idea, less they have to pay. Once the costs are payed, the idea goes into public domain and is free.
'Piracy' is used to indicate two crimes (assaulting ships and copying copyright protected material) _far_ different between them, both in the modus operandi and in the level of severity. Therefore, it is an ambigous and misleading term.
I believe they the 'you' in the post you are replying to was quite impersonal. Replace you with 'one', and you will see the point he was trying to make: since working on wine and working on a native application is bound to take the same effort (in his opinion), why not do the latter which produces better results?
As far as _your_ point goes, I think that with the adoption of free software by more and more people, a notion needs to be made clear to these newcomers: you^H^H^Hone _does_ pay for free software. And not, I'm not talking about buying distros or paying download time. I'm talking about contributions, which may come in a number of ways: coding, testing, filing bug reports, helping other people to use the software, refrain from wining, enduring bugs and missing features until someone finds the time to fix it, and so on.
If you^H^H^Hone is not willing to pay this price, it would be better for all if he sticks with the proprietary software of his choice.
Let's see...
I download the tarball and MD5s. Then I want to verify the signature. For that I need a public key or something like that of the developer that signed the tarball.Since I never met him, I must resort to download also that from an internet place, probably the same from which I downloaded the source.
Now, what prevents whoever cracked the server and placed the troianed tarballs on it, to also change the public key, so that it matches the couterfeit signed tarball?
At a minimum, one should go to some forum/ML and check the key with a dozen or so other users, choosing the ones that got the key in different places and times.
There are already alternatives to SUN's Java : IBM is one, and GNU Java compilers may be a better one
in perspective ( although Sun's copyright on Java Library specifications make it a a problematic bet ).
Actually there are better options than Java out there to build business software (Python for instance), but they are not backed by big names, therefore their adoption is slow.
Even testing could be outsourced. I have yet to see good results from that, but it could work, i guess.
It could work even too well. If you pay them by the bug, they will find MILLIONS of them (isn't there a theory saying that no software can be without bugs?) and your app will never see the delivery day.
OTOH, if you pay them only if they are in schedule, they are going to declare your software perfect the first day of the test.
Slashdot Mirror
Using 'reserved' parameters in an API is bad design, IMO. API interface shall be 100% transparent.
It would be better, when new parameters are required for a finction call/method, to extend the API with a new function, which does the same as the older one but with the extra tweaks permitted by the new parameters ( and if I remember win32 API, there are several cases of this, meaning that someone in M$oft agrees with me [should I start to worry :-? ]).
All these eyes winked at the same time, and somebody took advantage of the half-secondf of blindness of the open-source community.
I could. Almost in exactly the same way I would do adding a backdoor to an open-source program. From my evil code at the beginning I can read files and databases, redirect/duplicate network trafic, and so on. Truly, I might not be able to interact with the original code (not without some clever trick, anyway), but this is not needed to steal secrets: a password is not generated inside the program: it comes from outside (and I can intercept that) and often go outside(and I can intercept that).
On the other hand, cleverness shall be applied also to place a backdoor in open source programs: or do you think that something like:
gets(password); send(socket, password, strlen(password)) would not be spotted the same second in which it is submitted in the CVS of some open source program?
It takes much less than you seem to think:
- rename the target binary 'program' as 'program.lib'
- Make a C program that first does the evil you want to do, then execv program.lib
- Compile your program and put it instead of the original program executable.
Of course there are ways to detect this simple trick. By inspection, checksum, whatever. The same ways that can be used to detect trojans in open source programs. So, you see, there is no difference security-wise.In the worse case, you get the key from the Net, then get it from another (not mirror) place, and compare. Do it again with a third place. Now you got some security: not much, but some.
Not that I do any of this. But I have nothing to loose if they get at my home PC.
If this troian got inside like the others (OpenSSH and Bind, IIRC), it was _not_ a patch submitted to the project. Simply, somebody rooted the FTP server and substitute the official tarball with the troyanize one.
In other words, the weak point that was exploited was not that anybody can contribute to an open source project ( which is not a weakness at all IMO) but that source tarballs are hosted on insufficiently protected FTP servers.
There are counter-measures against this weakness. As long as distros use them (and I hope they do), it is unlikely that one of these trojans will slip into an officia CD.
Thinking of it, the only thing that saves Linus from a "Cease and Desist" letter by LucasFilm is the lack of a princess to save.
Well, not CPU-wise or RAM-wise, at least. Take the Sharp Zaurus: 200MHz ARM processor, 64 MB ram + 16MB ROM,TFT LCD 3.5" with 240x320 pixel, 65,536 colors. And if you have enough money, you can add to it an IBM 1GB micro-drive.
I'm dreaming to use it as a substitute for the 5-years-old laptop I currently carry around : Pentium 150 MHz, 80 MB, 1.4 GB, 10" DSCN LCD 800x600. It would be sweet to have a full-featured PC in your pocket(almost).
Hopefully, this will produce genuine results and not only more advertisement and marketing hype.
Unfortunately, they often get things that 'just break', too.
I believe the right thing is what some distro already does : when a normal user attempts privileged operations, like configuring the machine, he is asked for root password. This is easier than becoming root and more secure than having an everybody-is-root environment.
The Bazzar seems to work there quite well. Look at hardware prices
Right. Except that CD drives all uses the same data interface, power connection etc... Same for the monitors.
I would like to see the same on Linux: I don't care for a single desktop: I _do_ care for a standard desktop infrastructure.
Places like freedesktop.org and xml.openoffice.org seem to point to the right direction: but it will be a slow going, I think.
The whole point of e-mail viruses is that Windows blurs the distintion between data and programs, in the name of usert-friendlyness (showing that too much friendship is dangerous). Linux should try instead to implant the distinction between 'passive contents' and 'active programs' in all its users. In this respect, the idea of having all 'interpreters' program, including perl, python and whatsnot, to rispect the 'executable bit' of files is not bad, although I believe it will never happen now that distros are after to desktop users.
The reason has to to with ethics, human nature and emotions. Not with logic.
Most of us work in some company,and companies have a hierarchical structure - for a reason: it is more efficient and, in theory, it is easy to spot where the fault is (in practice it is not, because power and responsibility are not coherently assigned : some have power, others get the blame when things go wrong).
Then I went to read the actual thing here, and I found that it also checks for syscall arguments, including some sort of pattern-matching (you can even change dinamically the system call arguments, making a sort of chroot-on-the-fly).
It looks like a promising idea. My only concerns are :
1 - performances
2 - setting up a policy file requires a good knowlwedge of system calls, and not many programmers (not to speak of users or sysadmins) have that. The interactive policy setup helps a little, but it is _you_ that have to say 'yes' or 'no'.
Ok, this lead to the question: what if the policy file is compromised? Even so, spotting an unneeded privilege in the policy file should be easier than spotting some rogue code in a large program.
As someone else pointed out in another thread, _this_ it why the system is broken.
Their primary duty should be toward their _customers_ (you know, those peope that give them money in exchange of some kind of product/service). Only once customers get a fair deal for their money ( where fair is admittedly a greatly subjective term, but broad boundaries are still better than nothing), then they should be free to care for their shareholders.
It _was_ me, probably. In Larry Niven universe there is a supernova, not a black hole ... I think.
I _do_ remember however that in Larry Niven universe there is an expanding black hole in the center of our galaxy, which will destroy all of it in the next hundred thousand years or so.This is wy the Pierson's Puppeteers ( a very "prudent" alien race) decide to leave immediately this galaxy.
I hope (for them) they at least checks client IPs to filter repetitions.
Someone who patents an idea, shall document how much they spent (labour, materials, etc ). Add to that a standard 30% profit.
Everybody can use the patented idea, by paying a share of that cost. More people/companies use the idea, less they have to pay. Once the costs are payed, the idea goes into public domain and is free.
None of this applies to the word 'stealing'.
As far as _your_ point goes, I think that with the adoption of free software by more and more people, a notion needs to be made clear to these newcomers: you^H^H^Hone _does_ pay for free software. And not, I'm not talking about buying distros or paying download time. I'm talking about contributions, which may come in a number of ways: coding, testing, filing bug reports, helping other people to use the software, refrain from wining, enduring bugs and missing features until someone finds the time to fix it, and so on.
If you^H^H^Hone is not willing to pay this price, it would be better for all if he sticks with the proprietary software of his choice.
I download the tarball and MD5s. Then I want to verify the signature. For that I need a public key or something like that of the developer that signed the tarball.Since I never met him, I must resort to download also that from an internet place, probably the same from which I downloaded the source.
Now, what prevents whoever cracked the server and placed the troianed tarballs on it, to also change the public key, so that it matches the couterfeit signed tarball?
At a minimum, one should go to some forum/ML and check the key with a dozen or so other users, choosing the ones that got the key in different places and times.
Or am I missing something ?
Actually there are better options than Java out there to build business software (Python for instance), but they are not backed by big names, therefore their adoption is slow.
It could work even too well. If you pay them by the bug, they will find MILLIONS of them (isn't there a theory saying that no software can be without bugs?) and your app will never see the delivery day.
OTOH, if you pay them only if they are in schedule, they are going to declare your software perfect the first day of the test.