Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Hi all.
I'm building a live CD (based on slax) which needs to block access to local hard drives.
slax has a boot option to disable hard drive detection, but this option is somewhat week - the hard drives appear in the KDE file manager, andthey can be accessed if mounted manually.
I'm looking for a more robust method.
any ideas?
my idea was to block the creation of sysfs entries for the hard drives - any pointers how to do this?
Actually it's much esier than this, you can just set the permissions to mount for only root or remove the ATA drivers from the kernel and re-compile, I would stick with restrict the mounting to root and set a random root password on every boot, it should be the fastest and easiest solution which also prevents sudo'ing and allows for you to use that root account to access the hard drives, why is it you do not want people accessing the HD's btw???
Limiting mount permissions seems to solve part of the problem (this is what I do now)
However, the hard drive still appears in the konquerer file manager under the storage media section - which is undesirable as it gives the impression the hard drives are accessible.
do you think removing the ATA drivers will solve this? do you know how it's done? will it still allow cdrom and usb storage access?
another optin is thought of is somehow modifying the KDE kio_slaves, but i didn't found relevant information.
this also will not disable hotpluggable drives and I'm not sure if it will work with KDE because I don't use KDE.
There is another solution however, you could remove the fs drivers in the kernel which requires re-compiling and reconfiguring the kernel sources. It all seems like alot of work tbh, why do you need to hide drives?
using hal-device I see that the device is marked volume.ignore=true.
However, it appears that konquerer ignores this.
as for the need - it's supposed to some kind of sand box live cd - so I want it to block access to the local hard drive to prevent potential damage.
The fact that the hard drives can be seen, even if they can't be mounted, is also problematic as users might not trust the system to be secure enough.
okay... which KDE are you using that you have konqueror, I was pretty sure Dolphin was now the standard but anywho, other solutions include, uninstall konqueror and dolphin and use nautillus this should solve all of your problems within the GUI, furthermore if you would like to block all devices and loose all your data when you reboot you can use
this should work although it won't stop you e-mailing your data to yourself or ftp'ing it and you can be sure you definately won't injure your HD's, personally I'd just use more caution as i'm sure a shell script could still damage the drives
Hi all.
I'm building a live CD (based on slax) which needs to block access to local hard drives.
slax has a boot option to disable hard drive detection, but this option is somewhat week - the hard drives appear in the KDE file manager, andthey can be accessed if mounted manually.
I'm looking for a more robust method.
any ideas?
my idea was to block the creation of sysfs entries for the hard drives - any pointers how to do this?
Ophir Yoktan
You can now buy hard drives that easily detach from outside the case. When you want to use your live CD simply remove it then replace when finished.
Also, a few hard drives have a physical write protection switch.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.