How to Build a Locked-Down Installation of Puppy

How to do things, solutions, recipes, tutorials
Message
Author
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.

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

#61 Post by Indy'spup »

looks like we're narrowing down the culprits, cool :)

One thing though, I had to pass on that great macpuppy, was just to heavy for this project. My latest issues with the i attribute have been with mijnpup, much lighter without enlightenment.

jukingeo
Posts: 53
Joined: Sun 20 Jul 2008, 16:45

#62 Post by jukingeo »

Hello All,

I am wondering if there was any progress made in regards to this topic.

I too am looking for a read-only system based on Puppy (I have Wary 5.1.1 as of now).

In my case what I would like to do is set up game room systems that would run a program called MAME (SDLMAME in Linux) and DWJukebox. (I do have other applications as well, but these two programs would be what I would mainly be using).

As far as I know, both programs run off of 'rom' information and thus are "read only".

Now the reason why I am interested in a 'read only' lock down once everything is set up is because I would like to put everything on a Compact Flash card instead of a hard drive. As most of you may already know, being flash memory, a CF card is sensitive to being written to many times. Thus I am very interested in something that would allowed to be run in ram, but then any saved settings would be discarded upon shut down instead of saved to the CF.

So even though my reason is different from the OP, the desired end result is the same.

Thank You,

Geo

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

#63 Post by rcrsn51 »

I am wondering if there was any progress made in regards to this topic.
What progress are you looking for? Have you tried it?

You would need to format your CF card in ext. That is required in order to edit the init file.

User avatar
Mechanic_Kharkov
Posts: 9
Joined: Sun 24 Jul 2011, 08:08
Location: Kharkov, Ukraine

The same issue troubles me day by day..

#64 Post by Mechanic_Kharkov »

Hi, All. I currently have a system without HDD, that boots from CD, then reads pupsave.2fs and pup-431.sfs files from sda1 (flash stick). Now I'm looking a way to tel the system to do not save pupsave file neither on shutdown nor periodically by a timer.
Sometimes the decision to discard current session comes during the session itself but not at boot time. And if I know that no important changes are made to system then there is no need to wait while system saves file (on my system it can take very long time when not under X). And it slightly differs from "Locked-down" installation" to "Sometimes locked-down" one, in other words "with user controlled session saving".
So, the questions are:
  • Is there any ability to intercept anywhere in system (configs, scripts, even kernel code) the entry point where actual session file save is initiated?
  • If it is possible, then where to dig (for newbie, pls)?
The main idea (to make backup file, and then restore it on start-up) is not such suitable because of flash write-endurance. And it would be a great to have an option to forbid pupsave.Xfs saving during session (not only at boot time).

I also found this post (about 'pfix=kiosk'). This sounds exactly what I need to implement in my own setup. But there is an idea only in the post, no implementation.

Hope for Your help.

Sylvander
Posts: 4416
Joined: Mon 15 Dec 2008, 11:06
Location: West Lothian, Scotland, UK

#65 Post by Sylvander »


Post Reply