Testing extensions for malware.

[Frank]

Before the upload, do you (the team) test user-contributed extensions for malware inside the compiled binary? If so, how?

[bmarkus]

Before the upload, do you (the team) test user-contributed extensions for malware inside the compiled binary? If so, how?

Independently of TC practice, do you seriously expect to get an answer? Knowing the test procedure it would help to create malware to bypass such a test.

[Frank]

Yes, I do expect a serious answer. "Trust us, we know what we are doing" would be a little poor ...

[bmarkus]

Yes, I do expect a serious answer. "Trust us, we know what we are doing" would be a little poor ...

You have never developed an NSA approved stuff

[Frank]

To clarify.

We all know that one shall not run software from random strangers on the Internet. User-compiled TC extensions are exactly that -- software from random strangers on the Internet. I would like to know whether the team has proper measures in place to detect malware in the binaries. And I would like to know what kind of measures these are, because people sometimes have ... astonishing ideas about security. You don't find out unless you ask.

This is not about "loyalty" or "trust," this is a technical question.

[spence91]

The author of the TC extension is uploaded along with the file, if you don't trust the author; don't use it and compile yourself.

[bmarkus]

A detailed answer would reduce security in fact.

Are you using any other LINUX distribution? Do you trust them? And what is about WINDOWS?

[bmarkus]

The author of the TC extension is uploaded along with the file, if you don't trust the author; don't use it and compile yourself.

Hm... If you compile an application yourself, how can you guarantee that there are no hidden codes in it? You can trust in the author and others that someone already detected an unwanted part in the source code and alerted the open source community. It helps a lot, but doesn't give you 100% security.

You can go for conservative distro like REDHAT which comes usually with old version, wait 1 year and if it is still there, say it is secure ?

This is about malware. But there are also security gaps due to programming errors. Take for example the ssh key generation bug in Debian which was there for years....

A real security test is far behind of the resourses of most if not all disribution delelopment teams.

What is left is trust.

Sorry it is now a completely different discussion as the original topic, it is worth to separate.

[combo3]

According to GPL:

15. Disclaimer of Warranty.

THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

16. Limitation of Liability.

IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

In other words- Buyer Beware ....there are no absolute guarantees in life.

/off-topic

[philip]

The linux community is at its finest when well-formulated technical questions receive clear, on-topic replies. So far that hasn't happened in this thread. A reasonable question has been pushed aside (with gratuitous remarks about the one asking it) instead of getting answered. The tone of the responses comes very close to "Trust us, we know what we are doing" ... precisely the line the original poster correctly finds unsatisfactory. I write to encourage my respected fellow TC users to see if they (we) can do better.

Another interesting thread for security-conscious people is http://forum.tinycorelinux.net/index.php?topic=4088.0

[spence91]

Philip i don't see any gratuitous remarks towards the OP.

You are correct in that the replies are basically "Trust us, we know what we are doing", because that's basically what your asked to do every time you run an application that you haven't written yourself.

I don't personally know if there's any testing done on user submitted applications. If your worried about security you can roll your own packages or use a source based distribution.

[Jason W]

Any time you are using software, or eating food, you are trusting the ones who made it.  Nothing in life is 100% safe and there is no way to guarantee 100% safety.  But notice we have yet to have seen a maliciously made extension enter the repo.  Our base of contributors is skilled and proven trustworthy. 

If one does not trust TC or it's open development process, there are many closed development distros to choose from.  But then you are simply trusting their process just the same.

But the issue raised was auditing binaries for malicious code.  Malicious code could be anything under the sun added or taken away from the original source.  If there is such thing as a realistic test for that kind of thing that could be added to the extension auditing process then I will definitely consider it.

[philip]

If there is such thing as a realistic test for that kind of thing that could be added to the extension auditing process then I will definitely consider it.

This is a reasonable answer. It's essentially a simple "No" to the original question, wrapped with the perfectly believable assertion that the concept is some combination of unknown, unwieldy, or impossible.

I wrote in mostly because the OP is new and I wanted his fair question to receive a more welcoming response. Thanks to Jason, that's mostly fixed now. (I hope Frank agrees.) But it did get me thinking ...

Perhaps alternatives do exist. The Wikipedia article on linux malware concludes with a list of anti-virus programs, including several FOSS ones. Perhaps some of these work by recognizing the binary signatures of famous offenders, like the many commercial virus scanners for A Certain Other OS. Certainly checking binaries once as they enter the repo would be far more efficient than checking every file your computer touches at run-time. (I had to sit in front of a Windows box and wait for that just yesterday--ouch!) ... It would be a major project, though.

Personally I am content to run a tightly tuned firewall (iptables), include all the TCP/IP wrappers (/etc/hosts.allow, etc.), review the output of "sudo netstat -anp" occasionally to check that I recognize who I'm connected to, and trust the TC developers and submitters. I have learned these tricks the hard way, and regretfully agree that what may sound like excessive paranoia to the young feels like simple common sense to me.

[Jason W]

Though it is easy to insert malicious code into the source of any app, like adding the line "system("rm -rf /")" in one of the apps functions before compiling which would be undetectable, I don't mind adding assurance by scanning files with Clamav before uploading to the repo.  That would detect any of the known malware functions that would be present, and also works on ELF binaries.  I don't think there is a pressing need to do this, but it would be simple to do and protect the repo from a rare malicious extension being uploaded. 

I already do many automated checks of extensions' files, adding one more would be trivial. 

[Frank]

Jason W, thank you, that clarified it. As philip writes, "It's essentially a simple "No" to the original question" -- which is not the ideal state of matters, but definitely a perfectly clear answer.