How to Build a Locked-Down Installation of Puppy

How to do things, solutions, recipes, tutorials
Message
Author
User avatar
richard.a
Posts: 513
Joined: Tue 15 Aug 2006, 08:00
Location: Adelaide, South Australia

#41 Post by richard.a »

The Linpus Linux distro as used in the eeepc and which can also be downloaded (ver 9.4) for evaluation does something very similar to rcrsn51 post at the top.

It is certainly foolproof.

Good article guys.

Richard in Adelaide
where it is wet, windy and cold (by Ozzie standards)
[i]Have you noticed editing is always needed for the inevitable typos that weren't there when you hit the "post" button?[/i]

[img]http://micro-hard.dreamhosters.com/416434.png[/img]

Indy'spup
Posts: 50
Joined: Wed 11 May 2011, 15:32
Location: SoCal

#42 Post by Indy'spup »

rcrsn51 wrote:Most (all?) applications will save by default to /root, so any user data would be lost on a reboot. But there are ways around this.

In Firefox, you can move the hidden profile from /root/.mozilla to /mnt/home outside of the pup_save and replace it with a symlink.

You could do the same thing with any configuration folders like .gxine where the playlist is stored.

Similarly, the folder /root/my-documents could be symlinked to an external location. Users would just need to remember to save to that folder instead of directly into /root.

Ok the procedure is working great thanks again rcrsn51 I'm really happy with the mijnpup frugal install and the modified protected savefile. However it wasn't without a few incidents along the way, like manipulating the save file whilst booted into the same frugal install, like making backups of them and renaming for archiving etc etc. Most of the time I got it right but there were some occasions when my timing was off or I chose to reuse a savefile which had not been shutdown when the backup was made, causing an error at at next boot. yes I know I should have booted into a live cd to make the changes.. But I got to learn somehow right!!

I do have another question!!

If we move any user directories to another partition and symlink them back into the install, don't we need to set puppy to mount that partition for the directories to show up as expected?

If so, how about adding the mount command to the initrd script? without an unmount command?

or is that not the best way to accomplish the task?

nooby
Posts: 10369
Joined: Sun 29 Jun 2008, 19:05
Location: SwedenEurope

#43 Post by nooby »

When you make a change to the system, that change is immediately stored in the save.3fs. To "lock in" that change, boot off the Live CD, mount the Puppy partition and copy the current save.3fs over top of the save.bak file. Then reboot.

I wrote something I thought would work rather similar as a suggestion to somebody wanting some help but I got a very concerned contributer telling me it was a very bad behavior to suggest something like that.

Maybe what you recommend works due to the fact you use a Live CD.

Would it be dangerous to do the same in a frugal install where you "mount the Puppy partition and copy the current save.3fs over top of the save.bak file. Then reboot."

would that be due to puppy being in different pup modes in a Cd live and a Frugal live? I am not savvy enough to get if my suggestion really is exact like the one you suggest here but I thought it was when I wrote it and the person I learned it from had used it between 30 or 40 times without anything bad to happen to the save file. Him being in frugal install while doing it.
I use Google Search on Puppy Forum
not an ideal solution though

Indy'spup
Posts: 50
Joined: Wed 11 May 2011, 15:32
Location: SoCal

#44 Post by Indy'spup »

The other issue is protecting the boot and pupy files because it appears that the chattr +i command can be reversed by anyone using the chattr -i command.. maybe this is dependent on which root user is using the chattr +i command? Just thinking out loud..

nooby
Posts: 10369
Joined: Sun 29 Jun 2008, 19:05
Location: SwedenEurope

#45 Post by nooby »

When does one use this chattr +i command? Under what circumstances?
I use Google Search on Puppy Forum
not an ideal solution though

Indy'spup
Posts: 50
Joined: Wed 11 May 2011, 15:32
Location: SoCal

#46 Post by Indy'spup »

the chattr +i command is used to protect the files on HDD ie the frugal install. chattr -i would unprotect them.


Still yet another snag since puppy fails to continue loading when the lupu_520.sfs is copied into memory where the kernal crashes attempting to create a layered file system.. Works great for protecting the save file though.

I guess i attribute is perhaps not best for this purpose?
Last edited by Indy'spup on Thu 26 May 2011, 05:19, edited 1 time in total.

nooby
Posts: 10369
Joined: Sun 29 Jun 2008, 19:05
Location: SwedenEurope

#47 Post by nooby »

Ah that explain why it was impossible to change the Background image on a puppy OS.

the chattr +i command is used to protect the files on HDD ie the frugal install. chattr -i would unprotect them.

The layered thing in RAM appeared to change the background image but it never transferred to the HDD it only showed up as changed in RAM.

Cool one should be able to use that to dumb scripts and lure them to think they have installed malware and in reality them are only in a layer in RAM and get flushed at next boot
I use Google Search on Puppy Forum
not an ideal solution though

User avatar
richard.a
Posts: 513
Joined: Tue 15 Aug 2006, 08:00
Location: Adelaide, South Australia

#48 Post by richard.a »

Indy'spup wrote:Ok the procedure is working great thanks again rcrsn51 I'm really happy with the mijnpup frugal install and the modified protected savefile. However it wasn't without a few incidents along the way, like manipulating the save file whilst booted into the same frugal install, like making backups of them and renaming for archiving etc etc.
Actually frugal install is almost identical in operation to a Live-CD (apart from the CD's booting scripts versus the USB or what-have-you startups... so you can use similar thinking and apply it to both modes. The USB stick (or card, quite often, these days) contains both the .sfs and the .3fs files you need on a live CD boot, as well as the initrd (initial ramdisk) and vmlinuz (kernel).
Indy'spup wrote:Most of the time I got it right but there were some occasions when my timing was off or I chose to reuse a savefile which had not been shutdown when the backup was made, causing an error at at next boot. yes I know I should have booted into a live cd to make the changes.. But I got to learn somehow right!!
There is absolutely nothing to stop you from copying the save file with a slightly different name at any time should you wish. issuing the copy command won't work during an actual save.

Indy'spup wrote:If we move any user directories to another partition and symlink them back into the install, don't we need to set puppy to mount that partition for the directories to show up as expected?

If so, how about adding the mount command to the initrd script? without an unmount command? or is that not the best way to accomplish the task?
The answer IS "yes", you need to mount the partitions... preferably automatically, at boot. I run the MS Windows add-on suite called PortableApps (through WINE)at startup, with its directory structure copied to a "Data" partition I have on every computer, with a symlink to the desktop for manually running its startportableapps.exe file; and I really should put a link into the startup directory with a line like "mount /dev/sda5" (or whatever). Not sure if it would work but it's worth a try.
[i]Have you noticed editing is always needed for the inevitable typos that weren't there when you hit the "post" button?[/i]

[img]http://micro-hard.dreamhosters.com/416434.png[/img]

User avatar
rcrsn51
Posts: 13096
Joined: Tue 05 Sep 2006, 13:50
Location: Stratford, Ontario

#49 Post by rcrsn51 »

Indy'spup wrote:Still yet another snag since puppy fails to continue loading when the lupu_520.sfs is copied into memory where the kernal crashes attempting to create a layered file system..
Confirmed. Something has changed with the layered filesystem that prevents you from chattr-ing the main sfs file.

It also left a strange symlink in my frugal install. So I have deleted that option from the How-To.

Indy'spup
Posts: 50
Joined: Wed 11 May 2011, 15:32
Location: SoCal

#50 Post by Indy'spup »

rcrsn51 wrote:
Indy'spup wrote:Still yet another snag since puppy fails to continue loading when the lupu_520.sfs is copied into memory where the kernal crashes attempting to create a layered file system..
Confirmed. Something has changed with the layered filesystem that prevents you from chattr-ing the main sfs file.

It also left a strange symlink in my frugal install. So I have deleted that option from the How-To.
Oh man!! On the other hand this means I'm really not crazy :D

the i attribute doesn't mean the file can not be copied, only that it can't be deleted or renamed or a link made to it (maybe this is the key?) Strange thing is the attribute does not remain with a copied file, you can give a file this attribute then copy it and subsequently delete it!! interesting. Maybe here is a temporary work around for the issue.

I also need to experiment with the s attribute since possibly the attribute will not allow deletion (it zero's out the file then copies it bake afaik but will check on it asap..)

The whole plan is to prevent an accidental and hopefully malicious user from deleting any important file needed. Any determined and skilled hacker will have no trouble in messing with the Frugal install and even a live cd. I mean in five minutes a newbie like me found a huge security issue! If you can call it that since every puppy user has root privileges??

A user (who is allowed root access) can set the +i attribute and a frugal install will not boot again! not at least without some difficulty anyhow. Even a live cd will not boot without the pfix=nocoopy addition to the boot sequence. How many folks know this to be able to fix their install? I was looking at hot plugging the HDD to another machine to get around the security issue, then I found the live cd boot options.

Meanwhile there is a temporary solution, create a .bak file from the puppy.sfs file and secure it with the +i attribute. Then add to the script the command to copy and rename this file to a .sfs extension at the same time as as the save file is copied.

As a temporary fix I added this line to the script

Code: Select all

mount /dev/sda1 /mnt/data
cp /mnt/data/mijnpup520/pup_save.bak /mnt/data/mijnpup520/pup_save.2fs
cp /mnt/data/mijnpup520/lupu_520.bak /mnt/data/mijnpup520/lupu_520.2fs
umount /mnt/data
However I'm thinking about renaming the original files to something less obvious and hiding them somewhat.. Also a script to check if the sfs and save file are ok and decide to skip overwrite as the boot takes a couple of minutes now..


:)

User avatar
rcrsn51
Posts: 13096
Joined: Tue 05 Sep 2006, 13:50
Location: Stratford, Ontario

#51 Post by rcrsn51 »

What is your target audience for this setup? No matter how well you protect or hide the core Puppy files, a malicious user can just reformat the drive or corrupt it with something as simple as "dd".

There are already threads on how to make a "kiosk" version of Puppy. Maybe that's the approach you should be taking.

Indy'spup
Posts: 50
Joined: Wed 11 May 2011, 15:32
Location: SoCal

#52 Post by Indy'spup »

True there is great potential there too, but I think the dd commands would be less frustrating, at least the live cd would boot.

a malicious hacker needs only to set the i attribute on the main sfs file of any frugal install and the system will not boot. Additionally a live cd will also not boot.

Haven't attempted this remotely but I feel sure it's possible..

In order to change the attribute or check to see if it has been set the live cd needs the pfix=nocopy boot function. I can imagine how much frustration that can cause..



:)

User avatar
rcrsn51
Posts: 13096
Joined: Tue 05 Sep 2006, 13:50
Location: Stratford, Ontario

#53 Post by rcrsn51 »

Indy'spup wrote:a malicious hacker needs only to set the i attribute on the main sfs file of any frugal install and the system will not boot. Additionally a live cd will also not boot.
You would have to boot the CD using "puppy pfix=ram" to make it ignore the sfs file on the hard drive.

Indy'spup
Posts: 50
Joined: Wed 11 May 2011, 15:32
Location: SoCal

#54 Post by Indy'spup »

I hear you however pfix=ram didn't work on my repeated efforts using various v5.x puppies. Every live cd I tried failed to boot using pfix=ram, although "pfix=nocopy" prevented the sfs files from being read at all. Maybe this only effects ext3 formating?

User avatar
richard.a
Posts: 513
Joined: Tue 15 Aug 2006, 08:00
Location: Adelaide, South Australia

#55 Post by richard.a »

This I think is the key:
rcrsn51 wrote:What is your target audience for this setup? No matter how well you protect or hide the core Puppy files, a malicious user can just reformat the drive or corrupt it with something as simple as "dd".
When I was an "Insider" with Lindows > Linspire some years ago, this question was continually asked.

There is an old motto that applies to all forms of engineering, known as the KISS principle:
Keep It Simple, Stupid :)
rcrsn51 wrote:There are already threads on how to make a "kiosk" version of Puppy. Maybe that's the approach you should be taking.
I'm inclined to agree, and also feel that maybe we should ask the thread be moved to a more suitable part of the forums because this is not really the scenario the "average" or "target" user expects; it may cause confusion with some forum readers. It's really a development discussion about a specific usage, after all :)

I've made a kiosk which worked very well, using two CD drives.

The point about booting using pfix=ram to avoid the sfs file on the hard drive being booted from is an important point also raised.

The loss of time during bootup, resulting from doing that, is only of consequence where a very slow processor, older HDD and/or small quantities of antiquated slow RAM are involved. Kiosks are often slower than regular machines anyway, and this is accepted.

I would suggest that if you have your boot files/partition copied to a USB thumbdrive (that only you have) so that you can dd or even cp (assuming you are the admin of the cafe etc) this would solve your problem if it ever occurs, and you only need look deeper for solutions if the problem ever does rears its ugly head.

To fix all potential problems in advance is impossible, after all. And you will end up with all sorts of penalties in time - both now while looking at it, and later with all the extra operations a very simple and nice system will have to cope with, lol :)

Just my thoughts, guys :)

Richard in Adelaide
[i]Have you noticed editing is always needed for the inevitable typos that weren't there when you hit the "post" button?[/i]

[img]http://micro-hard.dreamhosters.com/416434.png[/img]

Indy'spup
Posts: 50
Joined: Wed 11 May 2011, 15:32
Location: SoCal

#56 Post by Indy'spup »

richard.a wrote:The point about booting using pfix=ram to avoid the sfs file on the hard drive being booted from is an important point also raised.
Thank you for you thoughts but may I suggest getting up to speed on this issue because it has been said several time already that pfix=ram does not prevent the core.sfs files from being read and interfering with the creation of a layered file system. I'm sure there are other valid parameters which will prevent the core sfs files from interfering , so far my observations have revealed pfix=nocopy to be successful. Whereas pfix=ram has not helped at all.
The loss of time during bootup, resulting from doing that, is only of consequence where a very slow processor, older HDD and/or small quantities of antiquated slow RAM are involved. Kiosks are often slower than regular machines anyway, and this is accepted.

I would suggest that if you have your boot files/partition copied to a USB thumbdrive (that only you have) so that you can dd or even cp (assuming you are the admin of the cafe etc) this would solve your problem if it ever occurs, and you only need look deeper for solutions if the problem ever does rears its ugly head.
Thank you again for your thoughts and suggestions. My feeling is no it is most definitely not acceptable, and we should be pushing the advancement of the technology not living in the past.

I'm new here so would hate to be stepping on someones toes, but honestly I feel the whole point has been missed.

Puppies have great potential and about the best chance the public has had to get comfortable with linux. Up until about a week ago I'd only heard of a Kernel Panic, however in this last week I've witnessed it maybe 20+ times already.. Not a great impression for Linux right?

From what I see, floppy drives have been extinct for more than five years, cd's are facing the same fate already. I'd say that the HDD is still here only because of some hint of reliability and cheap high volume storage, however flash drives in one form or another are the way of the PC in the near foreseeable future. If this tells you anything at all it's nobody is going to accept running an OS of a cd. Look at how many people ask "ho do we install a puppy to a Hard drive?? Why? because peeps want a faster technology the a cd, besides the cd and a thumb drive which offers some performance benefit can be removed and lost too easily.

What people want will ultimately drive the success of any technology.. but hey I've already hijacked the thread with too much with off topic thoughts, so..



Back on topic. This thread and the OP brought a great idea into the field, so far there is little competition in the quest for a locked down OS. Yes there are threads on building a Kiosk style pc, honestly though we're not there yet is my feeling. If we can take a few ideas from each thread then maybe we have something meanwhile this option is attractive.

:)

[/quote]
Last edited by Indy'spup on Thu 26 May 2011, 05:27, edited 1 time in total.

Indy'spup
Posts: 50
Joined: Wed 11 May 2011, 15:32
Location: SoCal

#57 Post by Indy'spup »

nooby wrote: the chattr +i command is used to protect the files on HDD ie the frugal install. chattr -i would unprotect them.
I'm sorry it was a typo but fixed now :)

User avatar
rcrsn51
Posts: 13096
Joined: Tue 05 Sep 2006, 13:50
Location: Stratford, Ontario

#58 Post by rcrsn51 »

Indy'spup wrote:however pfix=ram didn't work on my repeated efforts using various v5.x puppies. Every live cd I tried failed to boot using pfix=ram, although "pfix=nocopy" prevented the sfs files from being read at all. Maybe this only effects ext3 formating?
I just booted off the Live CD of Lupu 525 using puppy pfix=ram. It definitely ignored the sfs file on the hard drive and loaded the pristine version off the CD.

Indy'spup
Posts: 50
Joined: Wed 11 May 2011, 15:32
Location: SoCal

#59 Post by Indy'spup »

Clearly there are many variables involved. Under the above described test conditions the issue of prix=ram is 100% reproducible. Who knows, maybe it's related to the old machine I'm working with? maybe I should test the condition on another machine?

Bottom line is there should not be an issue with building a layered file system but there is. I mean the core sfs file should be considered as if on a readable only disk. But we now know its a linking problem, something which is not allowed with the i attribute. so far I've not had time to test what few other attributes which are availanle. You must agree this is undesputible. I know you were not expecting the issue so maybe it's a lucid thing?
Sure would be great is someone who had the skill to do something about it would be interested enough to take a look at the issue.

There is no quick solution for my specific requirement but the op for me is a fair solution, just needs a little work is all.
I'm grateful for your efforts


Thanks

User avatar
rcrsn51
Posts: 13096
Joined: Tue 05 Sep 2006, 13:50
Location: Stratford, Ontario

#60 Post by rcrsn51 »

Indy'spup wrote: You must agree this is undesputible.
Not without more testing.

I tested a bunch of Puppies - 4.3.1, Wary512, Lupu525, Macpup520. The ONLY one where I could NOT chattr +i the main sfs file was Macpup. I suspect that something changed in Macpup during the remastering process.

Post Reply