Build: Question : Contribution

[Fourdee]

Hi,

In the process of contributing some "first run" options for ARMbian. Mainly to allow the user to set wifi creds in a text file, prior to booting (eg: for NanoPi NEO Air) and have it applied automatically:
https://github.com/Fourdee/lib
Similar system we have in DietPi currently: http://forum.armbian.com/index.php/topic/2033-question-h3-unified-imaging/#entry16937

Question:

Whats the best place to put the following into ARMbian's sourcecode? End result is to copy the file to /boot/

cp /lib/config/armbian_first_run.txt /boot/armbian_first_run.txt

[ThomasKaiser]

Funny, i thought the whole Armbian approach to deal with WiFi passwords would've ended with a sane implementation but it's quite the opposite now, right? We're storing the passphrase in clear somewhere on an ext4 fs?

Hmm... I don't know whether storing WiFi authentication tokens on FAT can be considered even more bad.

@Fourdee please be aware that on the majority of OS images we don't use a FAT partition, that we deal with symlinks below /boot, that IIRC both Ethernet interfaces as well as WiFi aren't called eth0 and wlan0 everywhere (we support +40 SBC currently with 2 or 3 kernel versions per board) and that we ship with a bunch of different config files and simply link one to /etc/network/interfaces. There must be good reasons to adopt changes that destroy a lot and might work only on a small couple of boards with just one distro and one kernel variant each.

What might look like a reasonable approach based on DietPi design decisions might be impossible to implement when looking at it from an Armbian perspective. :)

[zador-blood-stained]

Not being able to change initial configuration on Windows hosts is not good, but IMO combining FAT filesystem and upgrades done with .deb packages is horribly bad and should be avoided at all cost. Compared to this I would prefer combining this configuration to some binary format (like u-boot's files made by mkimage) and writing this binary file somewhere between u-boot and first partition with dd. This can be implemented on any OS.

[ThomasKaiser]

Compared to this I would prefer combining this configuration to some binary format

Why _binary_? Obfuscation or another reason?

[zador-blood-stained]

Binary - to have a signature (to know if we have initial config or not), length (to know file length before reading it to not read garbage) and checksum (to prevent corruption). Simple encryption/obfuscation can always be added if needed

[Fourdee]

@ThomasKaiser

Funny, i thought the whole Armbian approach to deal with WiFi passwords would've ended with a sane implementation but it's quite the opposite now, right?

No. Please define your definition of what is "sane" in this instance?

we ship with a bunch of different config files and simply link one to /etc/network/interfaces

Yep thats fine, can be worked on to support various /etc/network/interfaces layouts.

IIRC both Ethernet interfaces as well as WiFi aren't called eth0 and wlan0

Yes, i'am well aware, we have a system in DietPi that automatically finds the 1st active eth/wlan index, might put that over here aswell: https://github.com/Fourdee/DietPi/blob/master/dietpi/func/obtain_network_details#L47-L69

We're storing the passphrase in clear somewhere on an ext4 fs?

If you looked at the sourcecode:

• The file which contains the user entered wifi details is deleted once its been applied. /boot/armbian_first_run.txt
• This system supports setting WEP and WPA passphases and Keys, not just WPA. Simplicity for the end-user.
• This system would benefit from a default 2 partition image, to allow end-users a simple and justified way of setting their WiFi creds before booting. But its not required.
• Use of this feature would be an optional choice by the end user. So no harm, no foul.

What might look like a reasonable approach based on DietPi design decisions might be impossible to implement when looking at it from an Armbian perspective. :)

Nothing is impossible, thats the "wrong" 😉 attitude. Its called improvement and reaching a middle ground of simplicity for the end user. I'am not sure how your work flow is setup, but I'am very capable of testing all scenarios will work, before i say its "completed".

Either way, i'am going to finish what I started, i'll then write up what this feature does, then its down to ARMbian if you want to merge it or not.

In the mean time, i'll ask this question again:

Question:

Whats the best place to put the following into ARMbian's sourcecode? End result is to copy the file to /boot/

cp /lib/config/armbian_first_run.txt /boot/armbian_first_run.txt

[Fourdee]

@zador-blood-stained

Compared to this I would prefer combining this configuration to some binary format (like u-boot's files made by mkimage) and writing this binary file somewhere between u-boot and first partition with dd. This can be implemented on any OS.

Sounds a great idea, but over-complication for something as simple as allowing the end user to set their WiFi creds on 1st run?

I suppose if it was well documented, supported and provides the user with a step by step walkthrough, could be good?

[zador-blood-stained]

Whats the best place to put the following into ARMbian's sourcecode? End result is to copy the file to /boot/

If you want this to be optional and decided by a person who builds the image, something like this would look OK in install_common in distributions.sh

[[ -f $SRC/userpatches/firstrun_config.txt ]] && cp $SRC/userpatches/firstrun_config.txt $CACHEDIR/sdcard/boot/

If you want this to be used always, the logic should look like this:

if [[ -f $SRC/userpatches/firstrun_config.txt ]]; then
  display_alert "Using firstrun configuration provided by user"
  cp $SRC/userpatches/firstrun_config.txt $CACHEDIR/sdcard/boot/
else
  cp $SRC/lib/config//firstrun_config.txt $CACHEDIR/sdcard/boot/
fi

[Fourdee]

@zador-blood-stained @ThomasKaiser

Another question, is there any specific reason for the eth1 entry in: https://github.com/igorpecovnik/lib/blob/master/config/network/interfaces.default#L8-L12

Is it used by any particular SBC model, or, is it just an example for end user?

[igorpecovnik]

Its just an example.

[ThomasKaiser]

Please define your definition of what is "sane" in this instance?

This question was directed at the other Armbian devs. I don't care that much about el cheapo Linux WiFi but at least WPA keys/passphrases should not be stored in cleartext anywhere (especially not on a FAT partition where files are just _deleted_ -- overwriting the contents with $something is IMO mandatory to make recovery harder -- same applies to not supporting WEP or other broken pseudo 'security' in 2016 any more, this is actively fooling clueless users).

We should not give up our focus on security for convenience. If it's not possible to transfer WiFi authentication in a more secure way we should refrain from trying it.

[ThomasKaiser]

BTW: I came accross PiBakery by accident. Various firstrun or startup tasks are defined as 'blocks' that can be defined/added. At least worth a look though it's 100 percent Raspbian focussed currently.

[Fourdee]

@ThomasKaiser

where files are just deleted -- overwriting the contents with $something is IMO mandatory to make recovery harder

Disagree. Surely you would need physical access to the SD card to even attempt a recovery?
You can't attempt to protect the user from having their SD card stolen or misplaced, hence this would be somewhat pointless overkill.

same applies to not supporting WEP or other broken pseudo 'security' in 2016 any more, this is actively fooling clueless users

We clearly see users in a different light. From my perspective, you need to understand the user is a person, they are capable of making their own decisions and taking the risk or reward that goes with their decision.
So Joe Bloggs has a outdated WEP network he got from his ISP 5 years ago, who cares? Thats the way Joe Bloggs wants to use it, let him. If its not secure enough for HIS needs, he can change it.

BTW: I came accross PiBakery by accident.

Very nice, looks fun.

Little story from my perspective:

When I setup a compiled ARMbian image for DietPi, ARMbian forces me to change the password which is great, however, dietpi is too short, so I have to do thisisalongerpassword. Once your 1st run script is finished, i do passwd and set to dietpi.

So the moral of my story is, the user will do what they like, regardless of what efforts you put into making specific rules for usage.

The other side of this story is "Well, shouldn't we also disallow passwords that do not contain a number and non-alpha character"?

My question to you and ARMbian is, where does all this end? Do you guys have a limit/guide of what level of "security" you want to force on the users system?

[zador-blood-stained]

When I setup a compiled ARMbian image for DietPi, ARMbian forces me to change the password which is great, however, dietpi is too short, so I have to do thisisalongerpassword. Once your installer is finished, i do passwd and set to dietpi.

We don't control this, any password strength rules come from adduser defaults (for new user) or from PAM (?) defaults (for forced root password change).

You can always change root password in build script with passwd to avoid doing it at first login.

[zador-blood-stained]

We clearly see users in a different light. From my perspective, you need to understand the user is a person, they are capable of making their own decisions and taking the risk or reward that goes with their decision.
So Joe Bloggs has a outdated WEP network he got from his ISP 5 years ago, who cares? Thats the way Joe Bloggs wants to use it, let him. If its not secure enough for HIS needs, he can change it.

We don't restrict users, we just try to use sane defaults. If user wants to use WEP encryption, he'll have to look at official Debian/Ubuntu documentation, where he will be reminded a lot about insecurity of this setup.

In any case in my opinion setting wireless options prior to first run looks like over-complication for most boards except for OPi Lite and NanoPi Neo Air.

[ThomasKaiser]

@Fourdee

Surely you would need physical access to the SD card to even attempt a recovery?

Do you really don't understand the difference? If you do a rm on a FAT filesystem the file will be only marked as deleted in the file allocation table and the whole file can be reconstructed absolutely reliable by various tools.

If you overwrite the file its contents also remain unaltered on the card but the card's FTL will hide it from higher layers (and also from the average user so it requires huge efforts/knowledge to get the contents). On flash media nothing will be overwritten, pages will be marked as deleted one layer below and if their contents is only partially changed this will be copied to new pages. Also chances are great that the data will be overwritten soon since the FTL assigns the specific page to an Erase block that will be deleted soon and overwritten later. Therefore choosing the amount of data to overwrite sensitive stuff with that is twice the Erase block size is good practice. And by immediately overwriting the file with new random data of the same size again it is ensured that the original data will be part of an Erase block pretty soon and gets physically erased on the card.

This is a fundamental difference and I really hope that practices that do not pay attention to security best practices at all won't be accepted in Armbian. Time to stop here.

@zador-blood-stained I fully agree regarding both boards. Let's wait or let Igor ask whether the AIR comes with a pre-populated eMMC. If that's not the case (as it's outlined in the wiki) then we could simply adjust boot.scr and /etc/fstab on the AIR image directly pointing to /dev/mmcblk1p1 and activate _g_serial_ like you did for OPi Lite already. Then users can flash the image directly from their PCs or Macs and do the initial setup over serial console (or if they use our build system they can adjust everything to their needs as they do today already, skipping user creation, setting network up differently, whatever)

Regarding Lite I don't remember people complaining in the forum having trouble with initial setup.

[zador-blood-stained]

@zador-blood-stained I fully agree regarding both boards. Let's wait or let Igor ask whether the AIR comes with a pre-populated eMMC. If that's not the case (as it's outlined in the wiki) then we could simply adjust boot.scr and /etc/fstab on the AIR image directly pointing to /dev/mmcblk1p1 and activate g_serial like you did for OPi Lite already. Then users can flash the image directly from their PCs or Macs and do the initial setup over serial console (or if they use our build system they can adjust everything to their needs as they do today already, skipping user creation, setting network up differently, whatever)

I hope to start implementing UUID based rootfs before that

Regarding Lite I don't remember people complaining in the forum having trouble with initial setup.

https://github.com/igorpecovnik/lib/issues/368

[igorpecovnik]

FA folks is currently on vacations. AIR looks like without a serial console, soldering first? What about having a second small FAT partition with initial_setup.txt and this is removed, overwritten with expanding default ext4 at first boot?

[ThomasKaiser]

AIR looks like without a serial console, soldering first?

People will power NanoPi AIR with a Micro USB cable since not even the power pins on the 4-pin header are populated. I don't know the settings used by https://github.com/zador-blood-stained/fel-mass-storage but in case they're rather conservative or like those we use for the NEO (not exceeding 2W in any case) then the AIR can start connected to every USB port on any host.

This way the image can be flashed directly to eMMC and if we set things up as for Orange Pi Lite already g_serial will lead to the AIR appearing as connected through serial console on first boot. Please compare with https://github.com/igorpecovnik/lib/commit/b98de7ebb376b8723b9f698dabc25c3017ade590

So basically the user connects the AIR to his PC or Mac, flashes the image directly to eMMC, unplugs/plugs the USB cable and then the Air appears as an USB-UART-dongle to finish the setup.

[zador-blood-stained]

What about having a second small FAT partition with initial_setup.txt and this is removed, overwritten with expanding default ext4 at first boot?

Windows may not like this layout, this needs to be tested

[igorpecovnik]

So basically the user connects the AIR to his PC or Mac, flashes the image directly to eMMC, unplugs/plugs the USB cable and then the Air appears as an USB-UART-dongle to finish the setup.

So for this case we don't need to bother because of wifi credentials.

Windows may not like this layout, this needs to be tested

First ext4, second fat is good for windows. First fat, second ext4, third fat is not working.

[Fourdee]

@ThomasKaiser

file will be only marked as deleted in the file allocation table and the whole file can be reconstructed absolutely reliable by various tools.

To be consistent, if that is the case, maybe ARMbian should also remove BOOTSIZE= option that allows for the vfat partition?
If running rm on that filesystem still allows for recovery, we must ensure that we prevent "clueless users" from copying their bankdetails.txt to /boot and then running rm on it!

This is a fundamental difference and I really hope that practices that do not pay attention to security best practices at all won't be accepted in Armbian. Time to stop here.

Some questions:

• Can you define exactly what your definition of "security best practices" are and why?
• Does this really need to be forced on end users? I mean, really?
• Do you enforce all "security best practices" with ARMbian, or simply pick and choose as needed, when it suits?

[igorpecovnik]

We don't have a written rules but security perspective plays an important role in decision making. Default Debian is universal system with moderate security and we try not to worsen the situation - if possible. Idea with (temporally) FAT partition might be a compromise since it's removed after first boot and security is not worsen. We need to have FAT boot partition as option since certain boards are not fully hacked to boot from ext4.

[Fourdee]

@zador-blood-stained

You can always change root password in build script with passwd to avoid doing it at first login.

I changed:

sed -i '/ROOTPWD=/c\ROOTPWD="dietpi"' lib/configuration.sh

Still asks me to change root password on 1st login. Wouldn't it be an idea to skip this if ROOTPWD!='1234' as the user has already defined the password they require? Otherwise ROOTPWD seems pointless as a changeable option?

[zador-blood-stained]

To be consistent, if that is the case, maybe ARMbian should also remove BOOTSIZE= option that allows for the vfat partition?

BOOTSIZE is an internal variable (not meant to be changed outside of predefined configuration) and FAT boot partition is still required for boards that use old u-boot versions that are not capable of booting from ext4 with their default configuration. In addition we still need to handle FAT /boot in case of A10/A20 boards with NAND storage.

[zador-blood-stained]

Still asks me to change password on 1st login. Wouldn't it be an idea to skip this if ROOTPWD!='1234' as the user has already defined the password they require?

Initial password is marked as "expired" here, so you need to "unexpire" it after this

[zador-blood-stained]

Can you define exactly what your definition of "security best practices" are and why?

• Predefined password for root account in case root access and password access are allowed in SSH config - is bad, so let's make sure that users are forced to change their passwords and that they can't put "1234" or "qwerty". Surely we don't need to create a botnet for DDoS attacks: https://krebsonsecurity.com/2016/09/krebsonsecurity-hit-with-record-ddos/
• Open or WEP wireless point; WPA/WPA2 wireless point with _predefined_ password are bad too

Does this really need to be forced on end users? I mean, really?

No, but we don't need to create bypasses for existing security measures in OS like password strength policy. Enabling root login via SSH is already bad enough and should be mentioned in documentation as possible security flaw

[Fourdee]

@ThomasKaiser

Lets try this a different way. I have a challenge for you if you are up for it.

Challange: Heres what I'd like you to do:

• Write DietPi image to any device
• Go through the 1st run setup, select some software if you like.
• Check the system for "security" issues you would deem as "unacceptable".
• Check for any areas where the user should be informed of a "risk" with a "warning message".

This way, I can see an example/insight of what your "best security practices" are, and, it may even help make DietPi more secure. Hell, you may even teach me a thing or two :)

[Fourdee]

@zador-blood-stained

Predefined password for root account in case root access and password access are allowed in SSH config - is bad, so let's make sure that users are forced to change their passwords and that they can't put "1234" or "qwerty". Surely we don't need to create a botnet for DDoS attacks:

I see, so the force of password change is to prevent easy passwords being generated by user. Would you guys consider a var in lib/configuration.sh that disables the password change? eg: ROOT_PW_FORCE_CHANGE=0

[zador-blood-stained]

I see, so the force of password change is to prevent easy passwords being generated by user. Would you guys consider a var in lib/configuration.sh that disables the password change? eg: ROOT_PW_FORCE_CHANGE=0

Not exactly, forced change is needed so you won't have active devices connected to who-knows-how-secure networks with root/1234 account available via SSH.

Would you guys consider a var in lib/configuration.sh that disables the password change? eg: ROOT_PW_FORCE_CHANGE=0

IMO only if root access via SSH is disabled with this option

[Fourdee]

@zador-blood-stained

IMO only if root access via SSH is disabled with this option

What about something like?

ROOT_PW_FORCE_CHANGE=1 #SECURITY WARN: If you set this to 0, you will not be asked to change root password on 1st login. This may provide a security risk if a insufficient password is used. Disabling this feature is at your own risk and not supported by ARMbian.

Allows the user to decide and warning hopefully prevent misuse and cover ARMbian's security goals?

[zador-blood-stained]

For the reference, password strength is enforced by pam_unix module

Simple
Is the new password too simple? This is based on the length of
the password and the number of different types of characters
(alpha, numeric, etc.) used.

[zador-blood-stained]

What about something like?

Sorry, I still don't want any options that would turn default security into this;

If anybody wants to set up build script with predefined root password for personal use (and not for distributing resulting images), any customization can be done in userpatches/customize-image.sh

[ThomasKaiser]

I have a challenge for you if you are up for it.

Waste of time. Thanks.

[Fourdee]

@ThomasKaiser

Waste of time. Thanks.

Shame, it would give everyone a insight into what you actually mean when you say "best security practices", rather than just pick it out of a hat when it suits you.

So, talk much, do nothing. Insightful.

[Fourdee]

@zador-blood-stained

Sorry, I still don't want any options that would turn default security into this;

So allowing the end user of "ARMbian build tools" to choose what password THEY want to use, even if its a complex password, even if there is a warning disclaimer, is a security risk?

You guys need to get off your high horse and listen to your end users, rather than try to dictate what your "cult" feels is definitive on everyone. Most people don't care what you think, we are all capable of making our own choices at the end of the day.
Christ, you even allow @ThomasKaiser to call your end users "clueless". Then you say something is "wrong" with a fancy picture to make your case. I mean come on guys, seriously, your so far stuck in your own little worlds, you fail to notice that the end user probably doesn't care what you think, they want to have the choice and use it how THEY want, without some guy using "its wrong" and "not best security practices" with no definition or facts to prove their claim.

Clearly, we are different projects with goals and mindsets. But the main thing i've noticed, I respect, support and listen to my users, you simply drill them to the floor.

I'am nearly finished with the new system, minor issue with a failed compile on Wheezy but i'll note that. Once completed, i'll send the push then i'am done with ARMbian. Good times.

[igorpecovnik]

There is no need for this level of talk.

We clearly have different philosophy, approach and we won't change our defaults since we choose not to for obvious reasons. We do listen to users all the time. Whole project is user oriented - we can't have this much of a ideas, they come from community. Sometimes people (we included) simply don't know what they/we want due to lack of knowledge, experiences or whatever reason. We are all only people, remember that.

System is open enough that anyone can adjust whatever he likes and we are happy to assist in this.

[zador-blood-stained]

So allowing the end user of "ARMbian build tools" to choose what password THEY want to use, even if its a complex password, even if there is a warning disclaimer, is a security risk?

End users can use whatever password they want as long as pam_unix is happy with it. If they want to set password to "1234", they are free to bypass this security measure - all documentation is available in public - but I won't give them an easy way to do this.

You guys need to get off your high horse and listen to your end users, rather than try to dictate what your "cult" feels is definitive on everyone. Most people don't care what you think, we are all capable of making our own choices at the end of the day.

I don't really care about target audience that can't remember a password that contains both letters and digits at the same time and is longer than 6 symbols (I don't remember exact requirements). And we don't dictate anything, these are default Debian/Ubuntu policies, and you are free to argue with upstream distribution maintainers about default security features.

You guys need to get off your high horse and listen to your end users, rather than try to dictate what your "cult" feels is definitive on everyone. Most people don't care what you think, we are all capable of making our own choices at the end of the day.

If we are still talking about root password and forced password change at first boot, then this is not "our case" but OS defaults for any adequate Linux distribution. If we are talking about allowing end users to store Wi-Fi passwords in plain test on FAT partition prior to first boot, then I don't see this as something "wrong" and I'm not against it if properly implemented. Root access or physical access to the device will render any existing security measure useless, and full FS encryption probably won't be a default Armbian option anytime soon.

Christ, you even allow @ThomasKaiser to call your end users "clueless". Then you say something is "wrong" with a fancy picture to make your case. I mean come on guys, seriously, your so far stuck in your own little worlds, you fail to notice that the end user probably doesn't care what you think, they want to have the choice and use it how THEY want, without some guy using "its wrong" and "not best security practices" with no definition or facts to prove their claim.

Armbian is non-commercial open source project, and "our little worlds" is our free time. If users want anything, they can either ask, do it themselves or move to another distribution, and we don't restrict their freedom. And so far I remember exactly 0 (zero) complaints about password strength policy and exactly 0 (zero) complaints about forced password change being "unacceptable" or "wrong".

[Fourdee]

@igorpecovnik

There is no need for this level of talk.

Agreed.

[Fourdee]

Odroid C1 + 8192cu:

• 🈯️ Jessie
• 🈴 Wheezy | build fails (see below)
• 🈯️ Trusty
• 🈺 Xenial | 8192cu r8188eu + do not support scanning. Possible underlying issue with build (see below)

Wheezy:

wheezy-ng-armhf.382...293.tgz:  200MB [ 168MB/s] [========================] 109%
[ o.k. ] Applying distribution specific tweaks for [ wheezy ]
sed: can't read /root/output/cache/sdcard/etc/default/ramlog: No such file or di                                                                 rectory
[ o.k. ] Applying common tweaks
sed: can't read /root/output/cache/sdcard/etc/default/console-setup: No such fil                                                                 e or directory
[ o.k. ] Installing kernel [ linux-image-odroidc1 ]
[ o.k. ] Installing u-boot [ linux-u-boot-odroidc1 ]
[ o.k. ] Installing headers [ linux-headers-odroidc1 ]
[ o.k. ] Installing generic firmware [ armbian-firmware ]
[ o.k. ] Installing DTB [ linux-dtb-odroidc1 ]
[ o.k. ] Installing board support package [ odroidc1 ]
[ o.k. ] Installing extra applications and drivers
[ o.k. ] Installing linux firmware [ 5.21 ]
[ o.k. ] Installing additional driver [ MT7601U ]
[ o.k. ] Checking git sources [ mt7601 old ]
[ .... ] Checking out
cp: missing destination file operand after ‘/root/output/cache/sdcard/lib/module                                                                 s/3.10.103-odroidc1/kernel/net/wireless/’
Try 'cp --help' for more information.
[ o.k. ] Installing additional driver [ RT8192 ]
[ o.k. ] Checking git sources [ rt8192cu master ]
[ .... ] Checking out
cp: cannot create regular file ‘/root/output/cache/sdcard/lib/modules/3.10.103-o                                                                 droidc1/kernel/net/wireless/’: Not a directory
[ o.k. ] Building deb [ armbian-tools ]
[ o.k. ] ... downloading sources [ temper ]
[ o.k. ] ... downloading sources [ BT utils ]
[ o.k. ] ... compiling [ temper ]
[ error ] ERROR in function compiling [ tools.sh:70 ]
[ error ] Error building [ temper ]
[ o.k. ] Process terminated
[ error ] ERROR in function unmount_on_exit [ debootstrap-ng.sh:576 ]
[ error ] debootstrap-ng was interrupted
[ o.k. ] Process terminated

Xenial:

[ o.k. ] Installing additional driver [ RT8192 ]
[ o.k. ] Checking git sources [ rt8192cu master ]
[ .... ] Checking out
cp: cannot create regular file ‘/root/output/cache/sdcard/lib/modules/3.10.103-odroidc1/kernel/net/wireless/’: Not a directory

[Fourdee]

Pull request sent. Marking as closed.