hi,how to make sure a Linux distribution or any open source software is not having any malicious programs or spying or information stealing stealth processes.

this question is in general for any Linux distribution or open source software. I am not talking about solydx or debian or Ubuntu or any thing specific.

I will describe in detail. Now a days so many ISO are appearing. I do not download software and build an OS. So how to make sure that any Linux Distribution or Open Source Software is not doing some thing with malicious intent.

The source is available for free download, but I only download a ISO [compiled binaries] if developer chooses to write some spying code and include it only in ISO, but not in source repositories, how will end user be aware of it?

the developer has full control , so can he write a piece of code ship it in ISO, and the process name will be like a very genuine process name [kio or kworker] but then it is doing some mischief. how will any body find that kind of malicious process which masks itself under a genuine name?

The Question is how Open Source Community in General is making sure of security aspects like that.If some one starts their own open source app or distro, should they get some approval by submitting their code to some authorised signatories like that? Or is there some kind of legal obligation which will prevent them from doing such things? or Is it just technically not possible to write a piece of code which will execute in the background, collect and send data to unauthorised servers, with out even leaving any kind of execution traces in system log files or not show up in pstree command or live in complete hiding in the OS. Is it even possible to write such a code?

this is a very general question on Linux and Open Source. Just curious, recently only I am giving some serious thought on security.

The source is available for free download, but I only download a ISO [compiled binaries] if developer chooses to write some spying code and include it only in ISO, but not in source repositories, how will end user be aware of it?

honestly, unless you know how to write a program and know the structure of the program, it's quite hard to notice whether if you have malicious code in your system even if you have the code. which basicly means...common user like you and me doesn't have any chance to know it. on contrary, it's easy for anyone with proper programming knowledge to spot it. most of malicious programs doesn't even have public source code so almost no one depends on the source code when he want to find a malicious program. they'll depends on tools like reverse enginering, hex codes, etc to do that. that's how people find security holes even in propietary softwares like windows.

in summary, open source doesn't really means you're safe.

it's a misconception that open source equals with safe. first of all, it's true that open source is considered safer than propietary ones because anyone could view the source code and works to fix it. however, it's under an assumption that everyone is a good guy and he'll report/fix the security holes he found. in reality, not every people immediately report the security hole he found. what makes open source better than propietary one is that lot of people keep watching on the code so even if someone didn't report it, someone else will. the benefit of open source is that any security holes will quickly be found and got fixed.

though, as you've said, open source doesn't really means that you'll safe. someone could alter his code and create a different binary file. this possibility did exist. so, how can we be sure that using linux is safe?

the answer lies on how modern linux distro were made.

first of all, modern linux distro isn't made by one people. it was made by a team. in debian and the derivatives (ex: solydxk, ubuntu, etc) we called them as "maintainer". they weren't just random people who randomly built a linux distro. in debian the process is actually quite strict, you'll need to submit a form to do it. before that, the communtiy need to know who you are. when you contributed to the community you'll got called as "contributor". that's how people build the reputation on the community. after having enough rep, people could submit a form to apply as a maintainer. they could be choosen as a maintainer after he got a recommendation from a "developer". a developer is the next higher rank than a maintainer. he'll supervise the works of maintainer and have higher authority on the system. above that is a team. above that is a committe...next...and the top of them is the project leader.

secondly, the maintainer works with source code as the basis. all the binary builds were done automatically by machine. what a maintainer needs to do is upload his source code and the rest of works will done automatically. it eliminate the possibiliy of someone forget to review his works before uploading it.

thirdly, the binary file isn't directly send to user. when a maintainer upload a source code, the binary file have to meet certain criteria to be accepted. after that there are some test needs to be done. after that, the binary file have to wait for some times so that people can test it (i.e: do reverse enginering, etc...). the time vary for 1-10 days.

this is roughly what happened in most linux distro. debian have an additional step, which is, creating a different branch called "testing" so that they could do more test on it. this additional process last roughly two years. after a binary file passed all of these test, roughly two years later it will released to public as a new release.

sounds crazy, ain't it? basicly debian got a rep for a stable and secure system because they implement this system.

wow ...just wow...let me thank you a lot for such detail explanation.I was only watching movies all the time. [more than 4 years I am using linux] but I did not even have the basic understanding of what goes into creating that movie.

Awesome, such simple and helpful replies thanks to you again.Very Helpful and Makes me believe more in Open Source Software.

is it possible to write a piece of code ship with the process name will be like a very genuine process name [kio or kworker] but then it is doing some mischief? is possible to use well established process names for my program. sorry not a developer or programmer. may be a dumb question.

md5 or hash binary footprint of an ISO, will it be unique for a distribution and a release. I will explain in detail. There was an incident when Linux Mint Server was compromised [recently happened may be 6months - 1year]. In that situation some body can upload ISO with inappropriate code.So my question is, for a Linux Distribution ISO on a particular release can I use the md5 hash key or binary foot print of ISO can it be a good identification for proper ISO. Apart from verifying the integrity of the downloaded file, can it used as a indication of a unique foot print for an ISO on a particular release.

hope I explained in proper way. I am looking for a source file to binary file mapping like that you know. Is it already there or it is my sleeping pills kicking in making me think weirdly?

is it possible to write a piece of code ship with the process name will be like a very genuine process name [kio or kworker] but then it is doing some mischief? is possible to use well established process names for my program. sorry not a developer or programmer. may be a dumb question.

you can give a name to every service as you want but you can't use it if it already running. for an instance, kworker would never work since it's part of linux kernel. kio might work on non KDE system. though, user will notice it easily. that being said, the name doesn't really important. linux works differently than windows. by default, linux gives limited privilege for every services. it doesn't really matter what the name as long as we give it proper privileges. well...linux services name is hard to distinguish so a common user like us won't know which one is "normal" anyways. luckily, with the limited privileges a fake service won't harm the system as long as it doesn't have an escalated privileges.

md5 or hash binary footprint of an ISO, will it be unique for a distribution and a release.

yes. it is unique for every file. not only iso but every md5 generated file should be unique. the accident with linuxmint wasn't because the security system is weak. it's rather because mint team was ignorant with security stuff.

one last question. please bear with my repeat question.I am looking for some kind of a source code to binary file mapping [after compilation]. Not a C developer. just curious.For example, I write a C Code Application, intended for Intel/AMD 64 processors and also compile it on such a platform. Get a binary file or executable file, package it as deb or rpm. so I got version V1.I change some source code, changing a few variable names, add a few lines of code here and there. Compile it again, get a binary file or executable file, package it as deb or rpm. so I got version V2.A end user who downloaded the published source code of my application V1, compiles it in his machine, intel based processor. basically he got the application now by compiling source code of my open source application. this is version 3.

Will the binary file be different between V1/V2 and V3?I expect V1 and V3 to be same in terms of binary foot print or bit by bit comparison. Can we use that to say, you know, for this source code this is the generated foot print of compiled code and it seems correct for the correct version number?

I totally get that for a Linux ISO what you said is good. I understand they are different for Linux ISO release. I am just extending that idea to a C-Program in general. Can we do that or say like that?

Please pardon my repeat question and I am not a developer, but will be an interesting thing to know.

it mainly depends on the compiler. as you can see, C need to be compiled to create a binary file. you'll also have different development environment. the component would be :1. source code.2. compiler.3. development environtment. you can't get same binary file unless you have same source code, compiler, and development environtmen. now, for the question,

Will the binary file be different between V1/V2 and V3?I expect V1 and V3 to be same in terms of binary foot print or bit by bit comparison.Can we use that to say, you know, for this source code this is the generated foot print of compiled code and it seems correct for the correct version number?

no. the source code can't be used as footprint for the compiled code. same source code can generate two different binary file. for some misterious reason, sometimes even same source code and same compiler can't generate exact same binary file. when we work using a compiler we didn't expect two same binary file but rather same behaviour from the generated binary file. in summary, same binary - no. same behaviour - yes.

I'll try to explain more but if it makes you confused you can ignore this part below.

now, to get deeper into compiler, every compiler works specifically for the processor architecture. every processor architecture have different set command so you'll need to compile your program based on your processor. in summary, when using a compiler, you'll compile a binary file based on your processor. for an example, when you're using an powerpc arch, you'll generated a binary file which only works on powerpc arch. this binary file won't work on amd64 procs. you'll need a cross-compiler to compile something for different procs. why is this important?

that's because you mentioned that "that person" is using intel based processor without specifying which architecture did he use and the OS. intel has two different processor and we have two different OS. for an example, even if you have same arch (i.e: amd64) but if you have different OS, (i.e: you're using 32 bit OS, while he is using 64 bit OS) you'll generate two different binary file. on a modern OS you can run a 32 bit software on 64 bit program so it doesn't really matter but since you mentioned about footprint, you might need to know about it.

hi,thanks again.I meant same intel based processor - in terms of word size or bit ness - 64 bit in both cases. but model may very i3,i5,i7 etc

a very simplistic scenario is:I write a C-Program. Compile it, use it happy with it. I am using Intel " core i3" 64 bit processor.I give the source code to my friend. He takes the source code and compiles it. with Intel "core i5" 64 bit processor. Other than that it is same OS like SolydX 9 with the C compiler available in the distribution's repositories.

Will we have same Executable file? Based on your replies I infer Not required. Bit by Bit comparison may be different. But the program execution will be the same way. If it is a Hello World program, it will say Hello World to terminal output when both of us execute the program. Same Behavior but with out identical binary file guarantee.

I mean I get your answer, so there is no strict reason to believe that the binary files will be same always even though functionality will be the same in spite of same processor, bit ness. No Guarantees on binary file foot print.

thanks for the clarification. it was very informative and good learning. Special thanks to you for the clarifications and taking time to respond to all annoying questions.

sincere regards and thanks to team solydx and members of this forum,harishkumar