My own distro

This forum is for Marvell Kirkwood devices such as the GoFlex Home/Net, PogoPlug v1/v2, SheevaPlug, and ZyXEL devices.

My own distro

Postby GBvjurckskxbaqC9xuh » Sat Jan 08, 2011 4:38 am

Anybody (esp. peaslaker) ...
I can create a snapshot and probably an install, but ...
I need to run a script on creation or install: ex. reset root password to root and reset system name to Arch Linux ARM install.
How can I incorporate that?

Thanks.
GBvjurckskxbaqC9xuh
 
Posts: 3
Joined: Tue Oct 26, 2010 4:25 am

Re: My own distro

Postby peaslaker » Sat Jan 08, 2011 10:39 am

UBIT scripts are now (v0.4) shell script language (busybox ash, so the Almquist Shell and not entirely compatible with bash but pretty good) and include a bunch of password tools (busybox versions of chpasswd, passwd etc.), and I think chroot which might be handy. Just log into the UBIT interactive mode and double hit the TAB key to see the busybox applets and binaries included in UBIT. It may be I need to put in user creation/modification/deletion tools. Can't remember if I include 'sed' either, but it sounds like you will want this too.

Distributing with a default password for root is one thing, but it is better practice for the installer to force user selection of a password, with the possibility of having root secured with an impossible password and running sudo from an authorised user account.

It is currently awkward/impossible to make changes (set password etc.) in the image that gets installed to NAND without doing a whole new snapshot/install cycle. If you were reasonably confident that your development root password is not easily crackable (bad assumption but let's go with it), you could just use the UBIT install script to set a password in the overlay. The back door to the system would be to run the UBIT ramdisk again and set/reset the password again. A separate password can also be set for the installed ramdisk, securing the interactive UBIT environment.

This will work for a writeable overlay, but a diskless (tmpfs overlay) system will be a complete automaton with no possible login. This doesn't really answer the hostname question and isn't really flexible enough to cope with multiple scenarios.

To achieve what you want I need to provide a way of intervening in 'snapshot' or 'prepare' macros. I propose that I can insert a hook to execute a user supplied script after the root filesystem has been extracted but before the image files are created.

The last bit to consider is that there is a gaping security hole in UBIT v0.4. UBIT scripts will happily execute arbitrary script written by anyone. I've kept quiet about this until now, but the original UBIT was 'secure' only because of the limited number of commands; v0.4 is inherently very insecure. This is because I wanted to get 'interactive' mode out there and working and get some use cases sorted out before backtracking to secure it.

I've been toying around with security ideas for v0.5 and I want to get the foundations in place for the new version. The blind script execution mode still has benefits for hiding complexity in an install process. I just tried altering the UBIT documentation to cover using interactive mode for initial installation but it just makes it harder for a newbie to follow. As it is (newly updated), the documention describes the guts of the install process in a couple of cut and paste operations. I don't want to lose that 'fire and forget' usability for canned installs and other minor operations.

Options I am looking at include:

1.Verifying against the root password in the ramdisk: if it is still on default value then fair game to execute scripts. If not, it is interactive only. Check that scripts are owned by root. (this is more limiting and/or less secure than it sounds; it introduces a disincentive for setting a password ).
2. Scrap the auto execution of scripts entirely (limiting but interactive mode is very reassuring to use, so maybe the loss is worth it ).
3. Scripts submitted won't be executed until you log on in interactive mode... (this just feels too bizarre and opaque, also scripts could be planted as timebombs)
4. Public/Private key encryption of the scripts (most secure/most complex; needs tools to be present in the 'host' operating system)

I seem to have diverted into my own topic on security, but the answer to your original question is that I need to give you a hook in the 'snapshot' script.
peaslaker
 
Posts: 101
Joined: Tue Sep 07, 2010 10:40 pm

Re: My own distro

Postby GBvjurckskxbaqC9xuh » Tue Jan 11, 2011 4:10 pm

Dear peaslaker,

"I need to give you a hook in the 'snapshot' script."

Will this make it into UBIT 0.5?

Thanks.
GBvjurckskxbaqC9xuh
 
Posts: 3
Joined: Tue Oct 26, 2010 4:25 am

Re: My own distro

Postby peaslaker » Tue Jan 11, 2011 8:50 pm

It will now.
peaslaker
 
Posts: 101
Joined: Tue Sep 07, 2010 10:40 pm

Re: My own distro

Postby GBvjurckskxbaqC9xuh » Tue Jan 11, 2011 9:54 pm

Thanks.
GBvjurckskxbaqC9xuh
 
Posts: 3
Joined: Tue Oct 26, 2010 4:25 am

Re: My own distro

Postby peaslaker » Mon Jan 31, 2011 10:30 am

UBIT v0.5 now on pre-release. Check out the post in the UBIT sub-forum. It should have all the bits you need.
peaslaker
 
Posts: 101
Joined: Tue Sep 07, 2010 10:40 pm


Return to Marvell Kirkwood

Who is online

Users browsing this forum: No registered users and 9 guests