operating systems - Will applications running in root mode be able to overwrite OS's or other program's memory section?
2014-04
vikkyhacks
I read here that any application running in root mode can issue a kernel call and execute in kernel mode. Is is possible that ANY application running in root mode can make a kernel call, go to kernel mode and tamper other program's memory area or mess with the operating system's memory section, cos almost all the tutorial's I find say's that kernel mode gives COMPLETE ACCESS to my hardware, and if it is this way wouldn't that be a great security flaw where the program just after acquiring the root level access would have access to any memory location on RAM/DISK ?
(I have Linux in my mind while I ask this question)
EDIT:
Well i am rreally convinced about the fact that in linux the memory is completely exposed, can someone explain if it is the same way in Windows and Unix
user55325
Yes, it's certainly possible - many Linux systems even expose memory via the two device files /dev/mem (for physical memory) and /dev/kmem (for virtual memory). You can access the kernel's virtual address space via /proc/kcore. Of course, it's not recommended to write to these devices, as you could easily trash your system.
I'm not sure why this could be considered a security issue, though - you generally have to be root to write to these devices, and if you have root access, you can already do anything you want.
Scott
You seem to be mixing apples and oranges. To quote the answer to the very question that you reference, “kernel mode and root are two separate ideas that aren’t really related to each other. The concept of running a process as root is a Unix/Linux term that means you're logged in as the administrator of the system. … Any process you run, whether as root or a normal user, generally runs in both user mode and kernel mode.” So an application running as root generally cannot just switch over and start running in kernel mode. All it can do is the same thing a non-root process can do: call a system function, which causes the operating system kernel to run in kernel mode.
That said, it’s true that most Unix-based systems give the root user privileges that are not available to non-root users/processes. For example, as user55325 points out, most Unix-based systems have pseudo-devices like /dev/mem, /dev/kmem, and /proc/kcore that grant privileged processes access to memory that does not belong to them. Also, root processes can kill any process, and can manipulate process in various ways through /proc. And, of course, root has full access to every file. So it’s certainly true that a process that gets root access has a lot of power; but that’s the way it goes.
For that matter, unless you always boot from an optical disc (CD/DVD) or the network, the operating system is stored in disk files, and an attacker who got access to your machine as root could rewrite the entire OS, and then sit back and wait for you to reboot. (And, oh yes, I almost forgot; a root process can reboot your system, too.) So, again, yes, root privilege is very powerful.
Alex
About a month ago I installed a security update that had new Kernek 2.6.34.x from 2.6.33.x), this is when the problem occurred for the first time.
After the install my computer would not boot at all, black screen without any visible hard drive activity (I gave it good 30 minutes on black screen, before took actions)... I poped in installation DVD and went in rescue mode to change back the boot option to old kernel (was just a guess where the problem was). After restart computer loaded just file, took a long time for it to start because of SELinux targeted policy relabel is required. Relabeling could take very long time depending on file size. I assumed that the update got messed up somehow and continued working with modified boot option.
Couple of days ago, there was another kernel update. I installed it and same problem as before. This rules out corrupted update theory... Black screen right after 'BIOS' screen before OS gets loaded. I had to rescue system again... Below is copy of my grub.conf file. I am fairly new to LINUX (couple of years of experience), mostly development and basic config... nothing crazy.
# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You have a /boot partition. This means that
# all kernel and initrd paths are relative to /boot/, eg.
# root (hd0,0)
# kernel /vmlinuz-version ro root=/dev/mapper/vg_obalyuk-lv_root
# initrd /initrd-[generic-]version.img
#boot=/dev/sda
default=2
timeout=0
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Fedora (2.6.34.6-54.fc13.i686.PAE)
root (hd0,0)
kernel /vmlinuz-2.6.34.6-54.fc13.i686.PAE ro root=/dev/mapper/vg_obalyuk-lv_root rd_LVM_LV=vg_obalyuk/lv_root rd_LVM_LV=vg_obalyuk/lv_swap rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us rhGB quiet
initrd /initramfs-2.6.34.6-54.fc13.i686.PAE.img
title Fedora (2.6.34.6-47.fc13.i686.PAE)
root (hd0,0)
kernel /vmlinuz-2.6.34.6-47.fc13.i686.PAE ro root=/dev/mapper/vg_obalyuk-lv_root rd_LVM_LV=vg_obalyuk/lv_root rd_LVM_LV=vg_obalyuk/lv_swap rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us rhGB quiet
initrd /initramfs-2.6.34.6-47.fc13.i686.PAE.img
title Fedora (2.6.33.8-149.fc13.i686.PAE)
root (hd0,0)
kernel /vmlinuz-2.6.33.8-149.fc13.i686.PAE ro root=/dev/mapper/vg_obalyuk-lv_root rd_LVM_LV=vg_obalyuk/lv_root rd_LVM_LV=vg_obalyuk/lv_swap rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us rhGB quiet
initrd /initramfs-2.6.33.8-149.fc13.i686.PAE.img
I like my system to be up to date... Let me know if I can post any other files that can be of help.
Has anyone else had this problem? Does anyone has any ideas how to fix this problem?
Brian Knoblauch
I've frequently found that Linux kernel updates break various systems and have just given up on keeping all my systems completely up to date. Some will boot certain kernel revs, others with seemingly identical hardware will not.