kurotsugi wrote:using linux doesn't guarantee you're safe. think about malware which attack using internet browser, java, or flash. you might safe from malware which specifically designed to attack windows but most of recent malware is designed to be OS dependent free. linux also have it's own vulnerability and malware specifically designed for linux did exist. and...don't forget abut NSA. they suspected anyone using linux and tor is a terorist. by using linux it means that you're more vulnerable from NSA attack.
an application program should not be able to infect its host o/s. this was established with System/360 back in 1964 and then reinforced by the addition of RACF in 1974.
I have been trying to find out more about these so-called drive by attacks. if you think back on comments from Charlie Miller at CanSecWest when Chrome introduced its "sandbox" saying like "I might have this bug and I might be able to get code execution but then getting out of the sandbox is another problem"
I think the core of the problem - so to speak - is this "code execution" thing. Which is why we have address space layout randomization (ASLR) and data execution prevention (DEP) .... in the most popular os. these things shouldn't be necessary where memory protection is properly implemented: code (text, in Linux) should run only on EXEC only pages. The code has to be re-entrant ( // PARM.LKED=(RENT... ) to do it --- i.e. the code page does not contain any data that it modifies -- thus it can be on a EXEC only page . and, conversely data should not be stored on pages marked for EXEC privilege -- should be READ/WRITE only .
I think LINUX does a better job of implementing this memory protection than the popular os does. if you think about it-- if you have a privileged program running in user-space with the application then ( this is a critical requirement ) that system code ( or any system code ) must be protected from deliberate or accidental damage.
the capability is there someplace in my notes i remember reading that it is used -- in Linux.
security has to protect the entire perimeter though and there are other areas that remain concerns. If an approved software package is allowed to install a DRIVER into the KERNEL ( Flash, perhaps ? ) -- that is a HUGE security concern: feeding bad data into such a driver could cause trouble -- if that data is not properly sanitized. If the data stream is complex ( Flash perhaps ) then sanitizing it could be troublesome...
this is a lot of conjecture here on my part; perhaps some of our kernel experts know more about this than I and might comment
Careless errors -- such as the recent BASH bug -- leaving a privileged logon exposed on the open net are human mistakes and not attributed to the software. HEARTBLEED was similar although a programmer's error -- failed to validate critical parameters in an input record. You never trust input records from remote sources.
Downloading/installing unknown software, again, is a human error,-- but one which happens all too often.
Today we see concern over FIRMWARE bugs: in particular the USB Device Firmware problem but also issues of equipment being improperly modified someplace in the distribution channel -- a la NSA.
so there's a lot of crap going on out there. the best we can do is keep communicating so that we get the word out on the things that do happen.
my daughter is delighted: her computer is running normally and she can get her lessons updated and posted.
