I just told you that I don’t know how to do it in Linux. But that it should be possible. That’s all I can help you with. On Feb 27, 2014, at 11:21 PM, paul g <pj.world at hotmail.com> wrote: > Ryan please could you please consider the GNU/Linux users out there who are struggling to secure their computers from the outside in also. > > Please take point to talk a bit about the 'PCI compliance options and features available' and the like also if I can ask could you please discuss about 'how to update bios under GNU/Linux - instead of an hp windows update package.' > > Do you have some experience with writing Bios type programs? > > I am sorry to be a bother. > > > Thank you for your time > > From: ryanjcole at me.com > Date: Thu, 27 Feb 2014 23:07:57 -0600 > To: tclug-list at mn-linux.org > Subject: Re: [tclug-list] Do strong root passwords prevent alternative access? > > No, not very likely. > > I know in Windows and Mac OS X how to encrypt hard drives but those, in my experience, require user intervention to decrypt to boot up. I’m sorry I cannot be of much further help on the subject. > > My previous job (from which I was recently let go) required PCI compliance and that meant, in my case, an encrypted hard drive. I have two passwords on my Mac to enter. The HDD password (22 characters) followed by my OS user password (11 characters). > > I am sorry to double post. Would it be wise to shut down the bios level boot drives what other measures could a limited knowledge user take in act at that point? What if the bios has no set password feature? is their a 'RAM' level feature one can burn into the systems single disk before even MBR or any other bootloader gets it? Is there a way to implement Bios password login without the Bios supporting password accessibility? > There must be a PCI compliance feature built into your OS. I just wouldn’t know where to direct you. > > > On Feb 27, 2014, at 10:45 PM, paul g <pj.world at hotmail.com> wrote: > > What can someone with limited experience do to prevent or postpone even a bit a situation where their root password is useless beyond unplugging the machine for the wall? If the Machine supports a bios password can that help in ones defense mechanism? > > Thank you, > > From: ryanjcole at me.com > Date: Thu, 27 Feb 2014 22:37:28 -0600 > To: tclug-list at mn-linux.org > Subject: Re: [tclug-list] Do strong root passwords prevent alternative access? > > No. Nien. Nada. Zilch. Nunca. Bubkis. > > Encrypted hard disks/drives/images are encrypted through and through. A root password is defenseless against a boot image - I can (and have, mind you, many times) take over a system using just a bootable CD or USB. I even reverse-engineered part of a vendor’s platform to show them exactly how prone to attack their hardware was. > > > > On Feb 27, 2014, at 10:34 PM, paul g <pj.world at hotmail.com> wrote: > > A simple question: Do strong passwords on a unencrypted harddisk 'root or sudo users' prevent really any sense of security if one chooses to boot into the system using a,an 'prefabbed .iso' or run a program that could search for a plain text password such as 'plain text'. Would the kernel version matter for security reasons in this event? > > Thank you, > > > _______________________________________________ > TCLUG Mailing List - Minneapolis/St. Paul, Minnesota > tclug-list at mn-linux.org > http://mailman.mn-linux.org/mailman/listinfo/tclug-list > > > _______________________________________________ TCLUG Mailing List - Minneapolis/St. Paul, Minnesota tclug-list at mn-linux.orghttp://mailman.mn-linux.org/mailman/listinfo/tclug-list > _______________________________________________ > TCLUG Mailing List - Minneapolis/St. Paul, Minnesota > tclug-list at mn-linux.org > http://mailman.mn-linux.org/mailman/listinfo/tclug-list > > > _______________________________________________ TCLUG Mailing List - Minneapolis/St. Paul, Minnesota tclug-list at mn-linux.org http://mailman.mn-linux.org/mailman/listinfo/tclug-list > _______________________________________________ > TCLUG Mailing List - Minneapolis/St. Paul, Minnesota > tclug-list at mn-linux.org > http://mailman.mn-linux.org/mailman/listinfo/tclug-list -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mailman.mn-linux.org/pipermail/tclug-list/attachments/20140227/6d3f3b09/attachment.html>