Re: ext2 attribute immutable
Albert Cahalan (albert@ccs.neu.edu)
Sun, 7 Apr 1996 23:21:15 -0400 (EDT)
>>>>> So, how does one need to modify /proc/1/mem to decrease
>>>>> the secure-level after getting root access? :)
>>>>
>>>> You don't need to. You can just do a ptrace() on init, or create your
>>>> OWN init process --- by using a careful, controlled fork bomb we can
>>>> easily create new processes until we are about to wrap pid, then kill
>>>> init and wait until one of our forks has a pid of 1.
>>>
>>> The fork attack shouldn't be possible. On SunOS, for example, when the
>>> PIDs wrap, they wrap to 101, not 1. Doesn't Linux do something like
>>> this? If it wraps to 1, this has to change -- conceptually, low PIDs
>>> are a privileged resource, so access to them must be restricted.
>>
>> Testing this with a bash script, I counted the pid up to 32,750 and then did
>> 'ps' manually until the pid wrapped. The pid did NOT wrap to 100 or 300, it
>> wrapped to '4'... skipping 1,2,3 which were taken.
>
> Ok, init can't be ptrace()d or kill()ed. You can try one of these:
>
> 1) Look in /System.map for securelevel, for example:
> 00000000001b8024 D securelevel
> Write a program that mmap()s /dev/mem and then does:
> *(int *)(map + 0x1b8024) = 0;
>
> 2) run "debugfs /dev/hda1" and kill_file anything with
> immutable attribute that you want to replace.
Block direct access to these devices.
> 3) If a kernel hacker blocked you from direct access to devices,
> do iopl(3) and program DMA ports + floppy controller to transfer
> a sector from floppy to the kernel page that has securelevel.
> (S)he can't block this, because X servers do the same iopl() call :)
This is why you get a GGI X server using the framebuffer device.
Since no such beast exists for x86, you should consider helping.
Join the list with mail to listproc@eskimo.com, with 'help' in
the body, or direct questions to irish@eskimo.com.
After you install your GGI X server, you may set securelevel to
something like 1000000000 without problems.