Linux - KernelThis forum is for all discussion relating to the Linux kernel.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
are we talking about a particular virus or just any virus... because most virii don't affect linux at all, much less the boot sector. All that resides in the boot sector in linux/unix is the bootloader (if that depending on which one you use)
I just meant virii in general. I'm in one of those heated debates about Mac/Windows/*nix security and I remember reading in a book that one reason Linux is safer is because of the inabillity of virii to affect the boot sector. I brought that up and was asked why. This isn't just for a the sake of a debate, I honestly wanted to know myself. Thanks!
LOL - this forum has a 2 cents icon, haha
Cool, haven't heard of a linux unix virus that can affect the boot sector, can't see how it could unless it somehow managed to get root access... not likely.
The main reason why this is so is ... the virus program can't get access to it.
Both Windows and Linux have excellent built-in security models. (The Windows default model is actually more advanced than Linux's default model.) Only trouble is, for millions of Windows installations ... security is turned off!
Any rogue program that comes in... on these unprotected Windows systems... finds that it has omnipotent powers on the machine. The computer will do, without question, anything that it is asked to do. Including rewriting the boot-sector, or modifying any file.
Want to put an abrupt stop to that, even on Windows? Tell your Windows pals that they should always log-in as "Limited Users." That they should set protections on every executable and DLL so that ordinary users cannot write to them. That they should enforce the available protections on the Registry keys.
Turnon the security, and it will work! If you continue to view the lock on your front door as a curious brass decoration, burglars will continue to steal your furniture. Both Linux and Macintosh OS/X (Unix...) have the security turned on.
This is exactly the sort of thing that Microsoft is, belatedly, trying to introduce to the Windows community ... and some users are howling and a seriously underinformed media is gobbling it up as "a story." They're critizing MS when they should be saying "great, it's about time they started doing that."
This is exactly the sort of thing that Microsoft is, belatedly, trying to introduce to the Windows community ... and some users are howling and a seriously underinformed media is gobbling it up as "a story." They're critizing MS when they should be saying "great, it's about time they started doing that."
Except when windows is particularly bone-headed and says that the one and only administrator account on the machine needs administrator's rights to do something... like, say, modify a system file to access some settings that M$ thinks that we don't need to know about. Even when in safe mode and the file is not in use.... (Especially when this is XP Pro and its the Administrator account.) Very bone-headed. I really wish sometimes that M$ would assume that some users might know what they're doing.
Sure, there's still a lot of software in the Windows world that was written hastily and lazily. But you can still adjust the permissions of a particular file.
Security does take a certain amount of work. It's "easiest" to just turn it all off, but when from 1/3 to 1/2 of all Windows machines get hit with viruses and malware not just once but on a regular basis ... "easy" is not good enough anymore. Windows has a good security model and there is a good reason why it exists.
When you get home at night, you lock your car behind you and you unlock your front door. There's a reason for those locks, too. When you drive through a residential neighborhood, you know that most of those (at least) front doors are probably locked. But, insanely, whe you drive through a section of the Internet, you know that most of the machines there are not. It is beyond insanity that most Windows users have no idea that their computers even have this capability, much less how to use it.
Fortunately for us, this has left the majority of malware writers very lazy.
Very true, I only leave the security turned off in my doze because there is nothing important on it, it gets virus scanned on a nightly basis, and its behind my very scary firewall. And upon further research it was one of the system files that can only be changed when the OS is not in use because the kernel locks it on boot up. Still a proper error message would have been nice.
I just meant virii in general. I'm in one of those heated debates about Mac/Windows/*nix security and I remember reading in a book that one reason Linux is safer is because of the inabillity of virii to affect the boot sector.
I think a virus could affect the boot sector (or MBR in a HD) on a Linux OS. When the first boot code runs, I believe it's in real mode. Here, a virus also runs in real mode, can do its thing, then pass control on to the OS, whatever it may be. This is how Windows/MSDOS boot viruses work. In fact, the boot code from Linux in bootsect.S is very similar to most boot programs, including boot viruses:
Recognize 0x7C00? The real issue is how the virus would be able to replicate. Would it be possible to write in real mode to the disks using the BIOS system calls? Yeah, but to access files on the underlying filesystem, be it ext2 or whatever, I'm not sure. I've not seen any example, and can image it would be very differicult, if not impossible.
The trouble starts after the virus would pass control to the kernel: the kernel flips to protected mode, and goes thru it's paces. Where does this leave the virus? Prehaps it could hook some area of the OS that was consistant across real & protected mode, such as maybe combining a file infecting element in with the boot virus. Most likely it would still need root access at some point, to do the actual disk writes.
In the day of the boot viruses, OS's ran in real mode, and didn't have to worry about this problem. They could hook 0x13 BIOS, replacing it's interrupt handling routine with it's own routine, and rest assured it would be called again and the virus would then again receive control back from the OS at various points. This allowed the virus to infect on open, not just execute or write, and to also protect itself if someone wanted to erase the virus.
But how would the MBR get infected in the first place? I am no virus expert, but it seems as if some poor sap would have to run the original infected file as root so that the virus could infect grub/lilo or whatever--which would require more cracking than I suspect most virus authors care to do.
Unfortunately, one reason why it can "get there" is (and I'm really not picking on you, verdeboy) is things like this...
Quote:
Very true, I only leave the security turned off in my doze because there is nothing important on it, it gets virus scanned on a nightly basis, and its behind my very scary firewall.
The means to stop these things at their source exist. They must be used. They're not "inconvenient," nor are they optional.
I think a virus could affect the boot sector (or MBR in a HD) on a Linux OS. When the first boot code runs, I believe it's in real mode. Here, a virus also runs in real mode, can do its thing, then pass control on to the OS, whatever it may be. This is how Windows/MSDOS boot viruses work. In fact, the boot code from Linux in bootsect.S is very similar to most boot programs, including boot viruses:
Recognize 0x7C00? The real issue is how the virus would be able to replicate. Would it be possible to write in real mode to the disks using the BIOS system calls? Yeah, but to access files on the underlying filesystem, be it ext2 or whatever, I'm not sure. I've not seen any example, and can image it would be very differicult, if not impossible.
Depends if it cares. Look at Michelangelo - all it did was overwrite the disk, starting at track zero.
Didn't give a rats arse what was on it - just trashes it, and copies itself to any boot sector found. If it hadn't been date-activated, it would have been murderous.
Don't think you could catch this ???. If it was on a floppy that was in your drive when you booted, you'd loose your *Linux* system.
No question.
D'oh - me still living in the last century ....
I always put one in - handy for things like BIOS updates, although typically even that can be done from a (support) CD these days.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.