If Linux is a protected-memory OS...
Anonymous Slacker
# cat /dev/zero > /dev/mem
cause a kernel panic? I expected it to only zero unallocated memory.
Grant
~$ cat /dev/zero > /dev/mem
-bash: /dev/mem: Permission denied
Once you're root, you're supposed to know better :) But sometimes
I cannot resist confirming the obvious...
root@deltree:~# cat /dev/zero > /dev/mem
<nothing at all, three open terminals locked up, the box died, then
WinAmp's buffer emptied and the music died too>
No kernel panic here, no more linux at all :) --> Hit the reset switch.
Why would you expect 'cat /dev/zero > /dev/mem' to do anything other
than to scribble over the memory image? Oddly, I half expected the
/dev/mem to be read-only, is why I tried out the insane wipeout ;)
Rope, foot, Ouch!
Grant.
--
http://bugsplatter.id.au
Anonymous Slacker
>~$ cat /dev/zero > /dev/mem
>-bash: /dev/mem: Permission denied
Of course...
>root@deltree:~# cat /dev/zero > /dev/mem
><nothing at all, three open terminals locked up, the box died, then
>WinAmp's buffer emptied and the music died too>
>
>No kernel panic here, no more linux at all :) --> Hit the reset switch.
No blinking caps-lock LED ?
>Why would you expect 'cat /dev/zero > /dev/mem' to do anything other
>than to scribble over the memory image?
Because a process shouldn't be allowed to write on a memory area that's
used by another process.
Loki Harfagr
well, it's not exactly what you tested, you actually tested that while
at userspace level a program would not be able to write on a
mem zone locked by another process, the superuser could still
plug the power cord or launch a pail of water on the CPU or
take a screwdriver and kill the drivers, or [:alnum:]+...
Lew Pitcher
(g_r_a...@bugsplatter.id.au) wrote:
> On Thu, 27 Aug 2009 04:01:20 +0000 (UTC), Anonymous Slacker
> <an...@example.com> wrote:
>
>>...then why does
>>
>># cat /dev/zero > /dev/mem
>>
>>cause a kernel panic? I expected it to only zero unallocated memory.
[snip]
> Why would you expect 'cat /dev/zero > /dev/mem' to do anything other
> than to scribble over the memory image? Oddly, I half expected the
> /dev/mem to be read-only, is why I tried out the insane wipeout ;)
Historically, the kernel provides /dev/mem (and /dev/kmem) to explicitly
permit priviledged applications to both read /and write/ to kernel and
userspace memory. This is how apps like the X server access video memory,
or sysadm system tuning apps accessed tunable kernel parameters.
--
Lew Pitcher
Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------
Grant
>Grant <g_r_a...@bugsplatter.id.au> wrote:
>
>>~$ cat /dev/zero > /dev/mem
>>-bash: /dev/mem: Permission denied
>
>Of course...
>
>>root@deltree:~# cat /dev/zero > /dev/mem
>><nothing at all, three open terminals locked up, the box died, then
>>WinAmp's buffer emptied and the music died too>
>>
>>No kernel panic here, no more linux at all :) --> Hit the reset switch.
>
>No blinking caps-lock LED ?
Running headless (well, keyboard but no monitor or mouse), I didn't
look at the keyboard as it's behind the main screens.
>
>>Why would you expect 'cat /dev/zero > /dev/mem' to do anything other
>>than to scribble over the memory image?
>
>Because a process shouldn't be allowed to write on a memory area that's
>used by another process.
Maybe so, a better place to ask might be linux-...@vger.kernel.org
aka lkml. But I suspect you'll find the answer would be along the
line there's also nothing to stop you doing 'cat /dev/zero > /dev/sda1'
while /dev/sda1 is mounted, which might wipeout your root partition
or whatever.
Oh yes, 'cat /dev/zero > /dev/hda9' did scribble zeroes over a
mounted partition just now ;) Things I'm mad enough to try...
Grant.
--
http://bugsplatter.id.au
Anonymous Slacker
>Historically, the kernel provides /dev/mem (and /dev/kmem) to explicitly
>permit priviledged applications to both read /and write/ to kernel and
>userspace memory. This is how apps like the X server access video memory,
>or sysadm system tuning apps accessed tunable kernel parameters.
This sounds like a massive security hole allowing processes to
circumvent memory protection.
I've just checked a remote FreeBSD machine I have an account on, and
there is no /dev/mem. OTOH, a root-writable /dev/mem is present on an
OpenBSD machine where I also have an account (maybe because X is
installed there?).
If anyone's got any pointers discussing the rationale for this design
choice, I'd be very interested in investigating the matter. Thanks.
Anonymous Slacker
>Maybe so, a better place to ask might be linux-...@vger.kernel.org
>aka lkml.
Good point. I think I'm going to peruse their archives.
> But I suspect you'll find the answer would be along the
>line there's also nothing to stop you doing 'cat /dev/zero > /dev/sda1'
>while /dev/sda1 is mounted, which might wipeout your root partition
>or whatever.
>Oh yes, 'cat /dev/zero > /dev/hda9' did scribble zeroes over a
>mounted partition just now ;) Things I'm mad enough to try...
That might actually come in handy. I did something very similar - except
I used /dev/urandom as a source - before sending in a machine to be
repaired, to avoid exposing sensitive data that had been on the HD.
Martin
Your expectation is inconsistent with the Unix concept. Like the heading of
chapter 12 says in the Unix Haters Handbook: Oh, I?m Sorry, Sir, Go Ahead, I
Didn?t Realize You Were Root.
You may like it or hate it, but it is the concept.
Anonymous Slacker
>Your expectation is inconsistent with the Unix concept. Like the heading of
>chapter 12 says in the Unix Haters Handbook: Oh, I?m Sorry, Sir, Go Ahead, I
>Didn?t Realize You Were Root.
>
>You may like it or hate it, but it is the concept.
That's very debatable. Since in fact there are things root cannot do
(e.g. removing a kernel module that is in use) I don't see why root
should be able to overwrite random chunks of memory at will.
Peter Chant
> Didn?t Realize You Were Root.
I suspect there would be a lot of abuse directed at those reponsible if root
were prevented from doing all sorts of things that a user is prevented from
doing.
Loki Harfagr
> Martin <n...@spam.invalid> wrote:
>
>>Your expectation is inconsistent with the Unix concept. Like the heading
>>of chapter 12 says in the Unix Haters Handbook: Oh, I?m Sorry, Sir, Go
>>Ahead, I Didn?t Realize You Were Root.
>>
>>You may like it or hate it, but it is the concept.
>
> That's very debatable.
as it should, that's a part of a choice for an OS
setup and which security enforcements you want and
which you wont, mixed with what part of each you wanted
but in the end just distate that it also has some
effects on parts you didn't clearly see before that
incident with [whatever tool opened up some doors of
perception at that time] :-)
> Since in fact there are things root cannot do
> (e.g. removing a kernel module that is in use) I don't see why root
> should be able to overwrite random chunks of memory at will.
on this false idea you already had the correct answer, in
untainted (read untriplebogussed) versions of Un*x the superuser
is just that, he has a giant screwdriver and all day the OS mumbles
prayers to the hyper bits in order to tame the superuser temper
so he won't get a testing idea about that screw and his screwdriver.
If you don't like the idea of the screwdriver replace that word
with any adapted word you'd prefer, like say "the superuser is
just this person with the big fluffy panda and he's sometimes
been witnessed while beating a RAM chip to death with the
panda left paw.
Grant
...
>If you don't like the idea of the screwdriver replace that word
>with any adapted word you'd prefer, like say "the superuser is
>just this person with the big fluffy panda and he's sometimes
>been witnessed while beating a RAM chip to death with the
>panda left paw.
Gawd 'elp us if linux root is ever downgraded like the administrator
group on windoze ;)
Grant.
--
http://bugsplatter.id.au
Grant Taylor
> Your expectation is inconsistent with the Unix concept. Like the
>
> You may like it or hate it, but it is the concept.
If you want an OS that is paranoid enough that it will not let its self
inflict self harm, have a look at (Open)VMS from DEC or any mainframe
type OS.
Grant. . . .
Keith Keller
>
> That's very debatable. Since in fact there are things root cannot do
> (e.g. removing a kernel module that is in use) I don't see why root
> should be able to overwrite random chunks of memory at will.
root can force removing a kernel module with rmmod -f (if the kernel
supports it).
--keith
--
kkeller...@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information
Henrik Carlqvist
> This sounds like a massive security hole allowing processes to
> circumvent memory protection.
As the root user you are really supposed to be above all security
mechanisms on the local machine. You are able to read files the owner does
not allow others to read, you are able to kill processes that belong to
others, and yes, you are able to do stupid things that can cause your
machine to hang, reboot or become unbootable.
Having so much power requires some sense. Doing dd if=/dev/random on a
hard disk partition might be a good idea if you know what you are doing
and want to wipe the contents on a drive. Doing the same on a mounted
or swap partition will probably end in a kernel panic.
There are athoer unixes that are able to partition root privileges in
different zones and there are other oses that don't have the same
administrator accout to handle both users and hardware. However Slackware
has the classic unix approach to the root account meaning that root can do
anythinng.
"Root being able to do this or that" on a local machine is not really
considered to be a security hole. Someone being able to gain root access
might be a security hole.
regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc3(at)poolhem.se Examples of addresses which go to spammers:
root@localhost postmaster@localhost
Grant
...
>Having so much power requires some sense. Doing dd if=/dev/random on a
>hard disk partition might be a good idea if you know what you are doing
>and want to wipe the contents on a drive.
if=/dev/zero is much much faster than /dev/random for wiping a HDD.
> Doing the same on a mounted
>or swap partition will probably end in a kernel panic.
Well, yes :)
Grant.
--
http://bugsplatter.id.au
+Alan Hicks+
Hash: SHA1
On 2009-08-28, Keith Keller <kkeller...@wombat.san-francisco.ca.us> wrote:
>> That's very debatable. Since in fact there are things root cannot do
>> (e.g. removing a kernel module that is in use) I don't see why root
>> should be able to overwrite random chunks of memory at will.
>
> root can force removing a kernel module with rmmod -f (if the kernel
> supports it).
In my experience, this never works though. If good ole rmmod alone
won't remove the module, rmmod -f never removes it either. I suppose it
could be useful in some cases, but I've never seen a situation where
forced module removal worked and non-forced module removal didn't.
- --
It is better to hear the rebuke of the wise,
Than for a man to hear the song of fools.
Ecclesiastes 7:5
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkqYFq8ACgkQNj1TaGS9H5KRqgCfVGTxP1TZuN3FBA678EK5gQ58
pMwAnibJdXGcw7H5moeUE7H3HDmvbj7c
=/QIK
-----END PGP SIGNATURE-----
Murat D. Kadirov
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 2009-08-28, Keith Keller <kkeller...@wombat.san-francisco.ca.us> wrote:
> >> That's very debatable. Since in fact there are things root cannot do
> >> (e.g. removing a kernel module that is in use) I don't see why root
> >> should be able to overwrite random chunks of memory at will.
> >
> > root can force removing a kernel module with rmmod -f (if the kernel
> > supports it).
>
> In my experience, this never works though. If good ole rmmod alone
> won't remove the module, rmmod -f never removes it either. I suppose it
> could be useful in some cases, but I've never seen a situation where
> forced module removal worked and non-forced module removal didn't.
I use it often when experiment with my tv-tuner (rmmod -f saa7134_alsa
&& rmmod -f saa7134). I suppose "force" option very usefull with
symbolic devices' drivers (modules).
--
Murat D. Kadirov
PGP fingerprint: 3081 EBFA 5CB9 BD24 4DB6 76EE 1B97 0A0E CEC0 6AA0
Henrik Carlqvist
> On Fri, 28 Aug 2009 08:22:46 +0200, Henrik Carlqvist
> <Henrik.C...@deadspam.com> wrote:
>> Doing dd if=/dev/random on a hard disk partition might be a good idea
>> if you know what you are doing and want to wipe the contents on a
>> drive.
>
> if=/dev/zero is much much faster than /dev/random for wiping a HDD.
Yes, it is faster, but some may say it is not as secure. I have heard
rumors that it it possible for data recovery professionals to restore also
old overwritten data from drives in clean rooms. If this is true I suppose
that a single overwrite with zeros will be easier to read through than
multiple overwrites with random values.
However, a single overwrite with /dev/zero is the fastest way and it will
not be possible to restore any data without physically disassemble the
drive.
Helmut Hullen
Du meintest am 30.08.09:
>> if=/dev/zero is much much faster than /dev/random for wiping a HDD.
> Yes, it is faster, but some may say it is not as secure. I have heard
> rumors that it it possible for data recovery professionals to restore
> also old overwritten data from drives in clean rooms.
With really old HHDs that is possible.
With actual HHDs it isn't.
The german computer newspaper c't has asked some well known data rescue
companies, they all told so.
Viele Gruesse
Helmut
"Ubuntu" - an African word, meaning "Slackware is too hard for me".
+Alan Hicks+
Hash: SHA1
On 2009-08-30, Henrik Carlqvist <Henrik.C...@deadspam.com> wrote:
>> if=/dev/zero is much much faster than /dev/random for wiping a HDD.
>
> Yes, it is faster, but some may say it is not as secure. I have heard
> rumors that it it possible for data recovery professionals to restore also
> old overwritten data from drives in clean rooms.
I'm very suspicious of these claims. I've heard them in the past, but
they ring hollow to me. I've done some work with Seagate's data
recovery specialists in the past, and they don't offer any such
service. The best they can do for "deleted files" is tell you they
will try, but if the data has been over-written at all, then it is
permanently gone and nothing they can do will restore it.
- --
It is better to hear the rebuke of the wise,
Than for a man to hear the song of fools.
Ecclesiastes 7:5
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkqcBxIACgkQNj1TaGS9H5LUOACeOypy0+k1x7nMZ8GwQiYK3N9u
qjEAnj3weLDGoGuKNKBs/oN+MCqtoF/S
=fMvL
-----END PGP SIGNATURE-----
~kurt
>
> I'm very suspicious of these claims. I've heard them in the past, but
> they ring hollow to me. I've done some work with Seagate's data
> recovery specialists in the past, and they don't offer any such
> service. The best they can do for "deleted files" is tell you they
> will try, but if the data has been over-written at all, then it is
> permanently gone and nothing they can do will restore it.
I guess it depends who you are trying to hide the data from, and how
much they want what is on your hard drive....
The claim is also that you want to use the random number generator when
prep'ing an encrypted hard drive so whoever is trying to decrypt it
won't know where the data starts. I'd think one would be able to figure
out what area had "random" data, and what had encrypted data since I
seriously doubt the encrypted data follows the same distribution.
- Kurt
Grant
...
>On 2009-08-30, Henrik Carlqvist <Henrik.C...@deadspam.com> wrote:
>>> if=/dev/zero is much much faster than /dev/random for wiping a HDD.
>>
>> Yes, it is faster, but some may say it is not as secure. I have heard
>> rumors that it it possible for data recovery professionals to restore also
>> old overwritten data from drives in clean rooms.
>
>I'm very suspicious of these claims. I've heard them in the past, but
>they ring hollow to me. I've done some work with Seagate's data
>recovery specialists in the past, and they don't offer any such
>service. The best they can do for "deleted files" is tell you they
>will try, but if the data has been over-written at all, then it is
>permanently gone and nothing they can do will restore it.
My impression is perhaps back in the pre-servo track days (damn near
20 years ago) you could read the deleted info because the write head
had to write a fatter track, the read head looks at a narrower part
of the track to allow for temperature drift (anyone remember 'disk
technician' from the '80s? Or, the silly 'spinrite').
So if you retry enough, and perhaps offset the head seek a bit by
interfering with the HDD electronics, yes, perhaps data could be
recovered after erasure -- it's a long shot for 'normal' people
without expensive resources.
Over the years the HDD started doing the self-calibration, then they
switched to servo tracks which stay calibrated as part of the track
seek operation.
Thus, the wipe with multiple pass wipe with random numbers method
seems to be well out of date.
Grant.
--
http://bugsplatter.id.au
+Alan Hicks+
Hash: SHA1
On 2009-09-01, ~kurt <actino...@earthlink.net> wrote:
> The claim is also that you want to use the random number generator when
> prep'ing an encrypted hard drive so whoever is trying to decrypt it
> won't know where the data starts. I'd think one would be able to figure
> out what area had "random" data, and what had encrypted data since I
> seriously doubt the encrypted data follows the same distribution.
Provided the encryption key is suitably random and the information
doesn't have a significant amount of repeated data, I would think it
impossible to determine where the encrypted data began and ended using
the above method.
- --
It is better to hear the rebuke of the wise,
Than for a man to hear the song of fools.
Ecclesiastes 7:5
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkqddF4ACgkQNj1TaGS9H5I/+QCeO+A+vhPMuxuj1nL6MfKS5sGH
zk0AnjytuxcqWyUe6Ja+pszXAcgnavzb
=T9AI
-----END PGP SIGNATURE-----
~kurt
>
> Provided the encryption key is suitably random and the information
> doesn't have a significant amount of repeated data, I would think it
> impossible to determine where the encrypted data began and ended using
> the above method.
The problem is that the random number generators aren't very random. I
believe the system ones also produce a uniform distribution, which would
probably stick out like a sore thumb.
- Kurt