Various forum members have expressed the advantages of running from a multisession DVD (which I have not tried yet...) and I can see advantages in running from a media which does not allow the executable code to be modified.
I want to run my netbook (which has no optical drive) on a puppy that is never able to be modified. (ie: which could never support a trojan or virus that survived across reboots).
I would like to know if others have succeeded in setting up their HDD based puppies to emulate running from CD/DVD in live session? (ie: no changes are EVER written to the puppy code on HDD). I have found a similar relevant thread here:http://murga-linux.com/puppy/viewtopic.php?t=42825 but various comments I have seen suggest that under some circumstances it is not trustworthy to simply lockout the save file mechanism.
Does anyone know if it is possible to somehow change permissions on all puppy files such that NOTHING in the operating system can be changed?
Maybe some feature of a remaster that would allow changes at remaster time but never afterwards?
"Read only" puppy on HDD
I currently have that sort of setup on a usb stick, but I wanted to have the puppy installed to inbuilt HDD and somehow make it "not possible" to alter the HDD code at all (like a ROM).
I thought there might be some pupmode that allowed the code to load to ram and allowed any necessary system writes to occur in ram, but never be written out to HDD because the HDD files had been marked as "read only" via locked down permissions or some other foolproof method.
I guess I dont really trust myself to get the pupmode (or grub stanza) correctly set up to ABSOLUTELY GUARANTEE that the HDD code will be unaltered at all times.
I wondered if something similar might even be possible by using a basic "secure" puppy (without internet capability) to boot the netbook, then transfer control via virtualbox to a separate readonly environment that is used for the internet stuff, but which never writes back to the original boot puppy.
Perhaps what I'm asking is: is there any puppy which has had ALL of its pupsave code completely removed, rather than just disabled/crippled intentionally as we have to do to get control of usb pupsaves.
I thought there might be some pupmode that allowed the code to load to ram and allowed any necessary system writes to occur in ram, but never be written out to HDD because the HDD files had been marked as "read only" via locked down permissions or some other foolproof method.
I guess I dont really trust myself to get the pupmode (or grub stanza) correctly set up to ABSOLUTELY GUARANTEE that the HDD code will be unaltered at all times.
I wondered if something similar might even be possible by using a basic "secure" puppy (without internet capability) to boot the netbook, then transfer control via virtualbox to a separate readonly environment that is used for the internet stuff, but which never writes back to the original boot puppy.
Perhaps what I'm asking is: is there any puppy which has had ALL of its pupsave code completely removed, rather than just disabled/crippled intentionally as we have to do to get control of usb pupsaves.
To see if your pupsave file has been modified after using one of those solutions, you could do and save an md5sum of your pupsave.
If nothing is added or changed in it, the md5sum should remain the same.
I know that is not a lot of help in finding a solution, but it is a way to check the pupsave file for possible modifications.
It makes me wonder though if setting up a pupsave file with your preferences and applications, creating an SFS file from it, if one could boot with pfix=ram, and use SFS-loa-on-the-fly to load the created substitute for the pupsave and have it work.
This is even if it required a restart of X.
An alternative would involve major programming to have a hard drive install act like a DVD/CD in that it would save sessions to the hard drive in place of a pupsave file.
As to virtual-box, as I cannot remember, is one able to save files to the underlying file system that might be called Z:?
If nothing is added or changed in it, the md5sum should remain the same.
I know that is not a lot of help in finding a solution, but it is a way to check the pupsave file for possible modifications.
It makes me wonder though if setting up a pupsave file with your preferences and applications, creating an SFS file from it, if one could boot with pfix=ram, and use SFS-loa-on-the-fly to load the created substitute for the pupsave and have it work.
This is even if it required a restart of X.
An alternative would involve major programming to have a hard drive install act like a DVD/CD in that it would save sessions to the hard drive in place of a pupsave file.
As to virtual-box, as I cannot remember, is one able to save files to the underlying file system that might be called Z:?
Interesting idea. It raises the question about how puppy treats an sfs - I presume an sfs must be a read-only filesystem that remains unchanged when it is unloaded at shutdown time?8-bit wrote:It makes me wonder though if setting up a pupsave file with your preferences and applications, creating an SFS file from it, if one could boot with pfix=ram, and use SFS-loa-on-the-fly to load the created substitute for the pupsave and have it work.
So I wonder if the browsing environment could be totally included in an sfs and not need to even write to a pupsave at all?
Or maybe it might be possible to "wrap up" a browsing sfs inside a virtualbox session?
(just spitballing ideas here...)
Put your custompuppy.iso on a usb pendrive by unetbootin or universal installer. Don't give write permissions to your pupsave. Every time you want to run puppy in "safe mode" boot the netbook with the pendrive in ram mode and then copy the "fixed" pupsave to hd. Give it write permissions on the hd. On the hd at root directory leave initrd.gz, vmlinuz, the sfs of your puppy and syslinux.cfg in which you'll have changed pmedia=usbflash with pmedia=atahd. Reboot with option "puppy pmedia=atahd" and load the pupsave on hd. Now you can remove the pendrive. Closing the session delete the pupsave on hd: you can do it the next time you need to boot in "safe" mode. Delete the old pupsave on hd and substitute it with the fixed pupsave from pendrive. Could it work for you?
As far as I can tell, the puppy sfs in my frugal install folder should be a "read only" filesystem. Why? Because it gets loaded from the sfs into ram - there should be no reason to write to that sfs.
If that is the case, why does my image below show that the sfs has write permissions set? Why should this ever need to be the case???
If these permissions could safely be set to read only I think that would satisfy my requirements. (Then all I would have to do is make sure a savefile was never created, and delete any that DID accidentally get created)
If that is the case, why does my image below show that the sfs has write permissions set? Why should this ever need to be the case???
If these permissions could safely be set to read only I think that would satisfy my requirements. (Then all I would have to do is make sure a savefile was never created, and delete any that DID accidentally get created)
- Attachments
-
- sfs writeable.png
- (39.98 KiB) Downloaded 920 times
"Read only" puppy on HDD – (Of netbook)
Hi greengeek,
You are aware of my fondness for simple solutions, so I am going to suggest that instead of using the hard disc, you just do a manual frugal install to a FAT32 SD card instead. This of course assumes that your netbook is capable of booting from a bootable SD card. There a few that will not.
Here is an example using Magoo V6 with all the files just in the root, the card having been made bootable with syslinux.exe from XP. [syslinux.exe -f -m -a X:]
Syslinux.cfg is as simple as possible comprising of just a single line:
Once you have created the save-file, installed any extra pets and imported any bookmarks install pupsaveconfig-2.2.5 and set it initially to “ask at shutdown
You are aware of my fondness for simple solutions, so I am going to suggest that instead of using the hard disc, you just do a manual frugal install to a FAT32 SD card instead. This of course assumes that your netbook is capable of booting from a bootable SD card. There a few that will not.
Here is an example using Magoo V6 with all the files just in the root, the card having been made bootable with syslinux.exe from XP. [syslinux.exe -f -m -a X:]
Syslinux.cfg is as simple as possible comprising of just a single line:
Code: Select all
default /vmlinuz initrd=/initrd.gz pmedia=usbflash- Attachments
-
- sdhc_magoo_v6.jpg
- (44.93 KiB) Downloaded 923 times
Regards ETP
[url=http://tinyurl.com/pxzq8o9][img]https://s17.postimg.cc/tl19y14y7/You_Tube_signature80px.png[/img][/url]
[url=http://tinyurl.com/kennels2/]Kennels[/url]
[url=http://tinyurl.com/pxzq8o9][img]https://s17.postimg.cc/tl19y14y7/You_Tube_signature80px.png[/img][/url]
[url=http://tinyurl.com/kennels2/]Kennels[/url]
Supplementary Question:
If I am running in ram (live session with no pupsave) and I write a file to a usb stick - is that file actually written? (I believe so. I am unaware of this having failed for me in the past)
Is this a different set of circumstances to the situation where I HAVE created a pupsave, but then disabled any new saving? If I HAVE got a pupsave, but have disabled any saving, what happens to a file that I try to save to usb? Does that file stay in ram, awaiting a "save to pupsave" command that never comes? (I suspect that I have lost files in the past because this situation is slightly different to a "live CD session" that NEVER had a pupsave in the first place...)
If I am running in ram (live session with no pupsave) and I write a file to a usb stick - is that file actually written? (I believe so. I am unaware of this having failed for me in the past)
Is this a different set of circumstances to the situation where I HAVE created a pupsave, but then disabled any new saving? If I HAVE got a pupsave, but have disabled any saving, what happens to a file that I try to save to usb? Does that file stay in ram, awaiting a "save to pupsave" command that never comes? (I suspect that I have lost files in the past because this situation is slightly different to a "live CD session" that NEVER had a pupsave in the first place...)
Re: "Read only" puppy on HDD – (Of netbook)
A characteristic I try to emulate without much success unfortunatelyETP wrote:You are aware of my fondness for simple solutions
Thanks for the SD suggestion - I recall that this netbook does boot successfully from SD using some puppies but not others (and always fails from a usb boot using syslinux 4.04). I will come back to this method if I can't satisfy myself of a suitable way of setting the HDD to my satisfaction.
Interesting - perhaps that might give me the "untouchability" I am looking for.rcrsn51 wrote:It gives you permission to delete the file.
EDIT :Once I've got the method sorted on my netbook I plan to use it on other machines aswell. In particular I have one machine which is used by a psychiatric patient who has a penchant for tinkering and experimenting - I currently have them running from CD so we can always go back to a known state, but it has become problematic always having to have the CD in the drive so I am trying to duplicate that functionality/untouchability on HDD
Last edited by greengeek on Fri 28 Jun 2013, 19:29, edited 1 time in total.
Re: "Read only" puppy on HDD
I am posting from a frugal install of an unmodified PhatSlacko5502 with no pupsave file. At boot it access's a series of startup scripts which create links, load SFS's and copy the contents of various .pets into the system. I can install .pets in the normal way but when I reboot they are gone. If I want changes that last I have to place them in a folder on the hard drive from which they are copied into the system. One of my startup scripts sets the PUPMODE=12 so it thinks there is a pupsave and doesn't ask to create one when I shutdown.greengeek wrote:I want to run my netbook (which has no optical drive) on a puppy that is never able to be modified. (ie: which could never support a trojan or virus that survived across reboots).
I have been able to make this work with all the 5 level puppies. Its a bit involved and I don't really have time to go into it right now but if you're interested I might be able to explain it more thoroughly this evening.
Cheers, J
I just tried changing the permissions for a puppy sfs file (pup-431.sfs) and found I can still delete it. Does that seem odd?rcrsn51 wrote:It gives you permission to delete the file.greengeek wrote:If that is the case, why does my image below show that the sfs has write permissions set? Why should this ever need to be the case???
I think if I remastered a puppy so it never tried to create a pupsave, and also turned the .sfs write permissions off permanently (which it looks as if I can do without undue consequences) I should be able to achieve what I was setting out to do.
Maybe.
-
TwoPuppies
- Posts: 77
- Joined: Wed 29 Dec 2010, 05:13
- Location: Melbourne, Australia
Are you aware that you can disable the "Save File" question at Shutdown, so that the system will never ask you if you want to create a Save File?
To do this:
Go to /etc/rc.d/rc.shutdown and open it as text.
Find the line
and change it to
Save the file.
What I usually do to create a "Read Only" Puppy on HDD is the following:
If, in the future, having a Save File becomes desirable, just change the line in /etc/rc.d/rc.shutdown back to what it was originally and the Save File option at shutdown will reappear.
To do this:
Go to /etc/rc.d/rc.shutdown and open it as text.
Find the line
Code: Select all
if [ $PUPMODE -eq 5 ];then #ifpupmode5Code: Select all
fi #end ifpupmode5What I usually do to create a "Read Only" Puppy on HDD is the following:
- 1. Boot from the Live CD.
2. Apply any customisations to the Operating System that I require, including the above modification to /etc/rc.d/rc.shutdown regarding the Save file. (Note that if you are running from a Live CD the pupmode number might be different.)
3. Do a re-master so that my customisations are included in a new SFS file.
4. Carry out a Frugal Install, using my newly re-mastered SFS as its basis.
- An Operating System that boots from a secure, read-only SFS file.
I still have all my personal customisations.
No mounted drives or partitions.
No automatic saves to a Save File (because there isn't one).
No annoying question every time I shut down about creating a Save File.
No possibility of creating a Save File by accidentally selecting the wrong option at shutdown.
If, in the future, having a Save File becomes desirable, just change the line in /etc/rc.d/rc.shutdown back to what it was originally and the Save File option at shutdown will reappear.
[color=#006699]What you really need is two puppies:
Puppy Linux, and the sort with four legs and a tail.[/color]
Puppy Linux, and the sort with four legs and a tail.[/color]
The only Puppy install that is truly unable to be written to and unchanged is a live Puppy CD/DVD that is burned as a closed session.
As a closed session you have locked the CD/DVD from being written on.
A multisession CD/DVD is still open to be written to.
That is why you can place saves on it when you shutdown.
The saves are burned to the CD/DVD at shutdown.
If you put Puppy on a device that can be written to (HDD, USB flash drive, SD card not locked, etc.....)
Malware always has the chance it could modify what is on the device.
Malware:
Any software designed to do something that the user would not wish it to do, hasn't asked it to do, and often has no knowledge of until it's too late. Types of malware include backdoor, virus, worm, Trojan horse.
Malware typically affects the system on which it is run, e.g. by deleting or corrupting files.
Even a closed session burned CD/DVD does not stop malware from doing something to what is in memory, while you are using it.
The Puppy sfs is always used as read only by Puppies operating processes, but nothing is stopping a properly written malware from changing that on a device that could be written on.
I would think it would need to be a malware that is designed to look for this read only condition and know how to change it.
As a closed session you have locked the CD/DVD from being written on.
A multisession CD/DVD is still open to be written to.
That is why you can place saves on it when you shutdown.
The saves are burned to the CD/DVD at shutdown.
If you put Puppy on a device that can be written to (HDD, USB flash drive, SD card not locked, etc.....)
Malware always has the chance it could modify what is on the device.
Malware:
Any software designed to do something that the user would not wish it to do, hasn't asked it to do, and often has no knowledge of until it's too late. Types of malware include backdoor, virus, worm, Trojan horse.
Malware typically affects the system on which it is run, e.g. by deleting or corrupting files.
Even a closed session burned CD/DVD does not stop malware from doing something to what is in memory, while you are using it.
The Puppy sfs is always used as read only by Puppies operating processes, but nothing is stopping a properly written malware from changing that on a device that could be written on.
I would think it would need to be a malware that is designed to look for this read only condition and know how to change it.
The things they do not tell you, are usually the clue to solving the problem.
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
