Pages

Search

Is dual-booting safe? - Forums Linux

Is dual-booting safe? - Forums Linux

Is dual-booting safe?

Posted: 29 Sep 2005 06:33 PM PDT

Charlie Gibbs wrote:

..... 
That's not their business. Not to mention the different flavors of
unix/linux filesystems. "Spying" on windows partitions and the registry
will suffice for a long time. In the worst case (of paranoia that is)
you can use encrypted partitions.
But then, just for fun, see my .sig :)
 
Never had a unsolvable problem installing linux for dual-boot. One has
to expect some difficulties and bios flaws, though, and never attempt
to do it without either enough faith and a knoppix cd (because unlike
most linux install cds in rescue mode, it can handle linux raid just
fine) handy, or (better) a good working backup - at least of the mbr
which easily fits on a floppy.
--
Longhorn error#4711: TCPA / NGSCP VIOLATION: Microsoft optical mouse
detected penguin patterns on mousepad. Partition scan in progress
to remove offending incompatible products. Reactivate MS software.
Linux woodpecker.fdns.net 2.6.13-mm3[LinuxCounter#295241,ICQ#4918962]

how to avoid BIOS during boot?

Posted: 29 Sep 2005 03:04 PM PDT

com wrote: 
 
 
 

No problem - misformatted partition (contents) or bios that cannot
read the contents. Msdos uses the bios for disk access. Since you have
already deterined that your bios cannot read much of your disk, that
is no surprise.

 

No problem - correctly formatted partition table. The partition
table is on sector zero and thus is perfectly within range of the
bios, which is what fdisk via msdos or notis talking to there.
 

No - that is NOTHING TO DO WITH LILO. IT IS A BIOS error (screams).
 

No it isn't. Please stop this. It's like watching a clown claiming
that people are only happy when he wears his red shoes. It is mistaking
cause and effect in a horribly muddled way.

Peter

LILO giving 01 01 01 01 error

Posted: 29 Sep 2005 01:31 PM PDT


<com> wrote in message
news:googlegroups.com... 

First: *IGNORE PETER*, he will snark at you to make himself feel like a
manly man, and his suggestions will contain no usable data as he pokes his
nose in the air and says "You're too stupid to know what I know", then he
handwaves soem argument that is usually (though not always) completely
irrelevant.

Second. For certain boot situations, grub is indeed better than LILO. The
key such situation is an old motherboard with certain BIOS limitations, and
a / partition that is not contained entirely within the first 1023 cylinders
of the disk. You can deal with the limitation with creating a /boot
partition at the beginning of that is less than 11023 cylinders long (or 8
Gigabytes with a typical disk layout). So a small 100 Meg /boot directory is
just about the right size for multiple kernels, a few grub config files,
etc.

Firewall software.

Posted: 28 Sep 2005 05:02 PM PDT

[Distribution snipped for follow-ups.]

In comp.os.linux.setup Jeffrey Goldberg <org> wrote:
 

The conventional way of doing that on a Unix system is with a security
regime that implements a "capabilities" model to allow restricting in
advance what each executable is and is not allowed to do -- such as
SELinux.
 

None lately. Their heyday on Linux was 2001-2003. Their food was taken
off the table by several things: 1. Eclipse of BIND8, wu-ftpd,
wu-imapd, qpopper, and lpd/LPRng (horrendously buggy network daemons) by
better replacements. 2. An end to the bad habit of distro installers'
(mainly Red Hat) defaulting to a ridiculous number of network daemons
including NFS/NIS(!) running. 3. Lack of a default IP/port filter.

Rundown on all of them to date, here:
http://linuxmafia.com/~rick/faq/index.php?page=virus#virus5

--
Cheers,
Rick Moen Support your local medical examiner: Die strangely.
com

pam, ssh, user account vulnerability

Posted: 27 Sep 2005 01:34 PM PDT

Enrique Perez-Terron <no> wrote:
 

Going from memory: The Tripwire binary, when started, calculates its
own md5sum and compares it against the one on record in the (signed,
encrypted) signatures database.

The next in a long series of possible questions you would then want to
ask me is how that system defends against an intruder who replaces the
Tripwire binary with one that merely pretends to recheck its md5sum
hash, and reports that it matches and is thus OK even though it isn't.

My recollection of the answer to that is even more vague: At least part
of it is a recommendation that you regularly reverify the integrity of
_all_ the important files using your private key on a different system
(e.g., the place where you receive Tripwire's signed, encrypted reports
via e-mail). Plus they recommend that you keep that binary on
write-protected storage.

The questions and answers go on at considerable length. For instance,
one of the obvious attack vectors would be to sabotage the system
crontab entry that causes Tripwire to generate, encrypt, sign, and
e-mail a report. So, you're admonished that, if you suddenly aren't
receiving reports when they're expected, watch out!