LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices


Reply
  Search this Thread
Old 07-09-2019, 04:05 AM   #1
n0rthst4r
LQ Newbie
 
Registered: May 2019
Location: Spain
Distribution: Ubuntu mostly
Posts: 11

Rep: Reputation: Disabled
Encryption? - How to secure a setup and bash scripts.


Hello everyone.

My company builds self-service point-of-sale equipment that runs a Linux system on IMX processor. I have to provide some technical support for the staff in charge of those units but I am not avaliable 24/7 and they may need some help at night, for example.

The units have an Ethernet cable and they accept SSH sessions so when I am servicing them I just SSH into them and type all the commands I need.

We are planning to send a device (like a cheap laptop or something) to the shops with some scripts to perform first aid.
These scripts do stuff like backup, permissions fix, etc... I have prepared a VirtualBox Ubuntu machine that boots directly to text mode, logins non-root user and then launches the main script, which will allow staff to easily perform basic first aid tasks by just picking a number, like as in a ATM.

"Welcome:
1. Fix permissions
2. Rebuild inventory
3. Etc...
Make your choice: 1-2-3
"
And then based on user choice a function or another script is called. This is already set up but these scripts contain plain-text passwords for SSH.

What I need to do is to "secure" the whole system so the staff can't:
- Break script execution: done with signal control
- Do anything else once the system has booted: done via .bashrc (launches main script and then, in case it finishes, shuts system down)
- Look inside my code: This is where I need help. If they boot the laptop with USB or take HD out and plug it to another computer they could look at my code and find out real passwords.

I have thought about some approaches but none seems to work as expected:
- Whole disk encryption (LUKS) with autodecrypt during boot. Once booted, they can't do anything else but follow the script so they won't be able to see what is inside scripts, even if they look from outside (booting from USB or whatever). I haven't been able to properly set it up to autodecrypt at boot. I have followed several guides suggesting to edit the crypttab file but I always end up with a broken system or asking for a password. I have thought I could write some kind of script and hide it somewhere to make it harder to find it but I don't know how to achieve this.
- Encrypted folder. Dismissed since .bashrc has to be encrypted so they can't modify it and do anything else.
- Encrypted whole home folder (ecryptfs). Would be fine since it hides .bashrc but I haven't been able to make in autodecrypt during boot. I wonder if there is a way of including the passphrase inside a keyring or something so they don't have to type it (and obviously learn it).
- Put everything inside a initramfs. I don't know if this is possible and if it would really make the system safe.

Maybe the best way is to choose a laptop with a soldered EMMC and prevent it from booting USB via BIOS and UEFI safe boot so the thing will only and only boot to an embedded storage device which can't be easily taken out but we would prefer something cheaper as sending it as a VirtualBox OVA (to use in their own VirtualBox) or inside a USB bootable flash drive they can boot in their laptops.

Any idea would be appreciated.

Thanks in advance for your help.

Last edited by n0rthst4r; 07-09-2019 at 04:38 AM. Reason: Title correction
 
Old 07-09-2019, 06:42 AM   #2
wpeckham
Senior Member
 
Registered: Apr 2010
Location: Continental USA
Distribution: Debian, Ubuntu, Fedora, RedHat, DSL, Puppy, CentOS, Knoppix, Mint-DE, Sparky, Vsido, tinycore, Q4OS
Posts: 3,046

Rep: Reputation: 1332Reputation: 1332Reputation: 1332Reputation: 1332Reputation: 1332Reputation: 1332Reputation: 1332Reputation: 1332Reputation: 1332Reputation: 1332
My initial ideas are:
#0 block anyone untrusted from access, and TRUST the rest.
#1 use keys so that passwords are not needed. This seemed workable until you got to the encryption part which does not lend itself to keys.
#2 Stop using shell for this purpose. Learn to code in something compiled, and only distribute binaries. Check the binaries to ensure that the critical security information is not easily extracted as a string.
#3 use something like blind-bash to obfuscate your shell scripts code and only distribute the obfuscated version.


If you try something, please revisit this thread and let us know what you like and do not like, and why. Others may face like situations.
 
Old 07-09-2019, 07:19 AM   #3
n0rthst4r
LQ Newbie
 
Registered: May 2019
Location: Spain
Distribution: Ubuntu mostly
Posts: 11

Original Poster
Rep: Reputation: Disabled
Hello and thanks for your reply.

I can't decide on the 0, that is on my managers, and they prefer to make this setup available for almost everyone.

I don't know if I can use keys. I suppose you mean adding private SSH keys to the point-of-sale so it only accepts SSH from the support computer, don't you? But I am afraid that is almost impossible since we have a lot, like three hundred or something like that.

I am on my way of the 3rd idea, I promise. It is the idea I liked the most. But isn't reverse engineering going to be a problem? I played decompiling some .EXE files long time ago and it was pretty easy. Correct me if I am wrong.

Blind-bash seems to do the trick, at least for the moment, but I would prefer something stronger like coding in C or whatever.

Edit: Managed to get luks decrypted via keyfile during boot. Maybe combining that plus Blind-Bash would be enough. Given this setup, .bashrc has to be encrypted so the system boots to what I need, unless other approach is suggested, don't you think?
In the current system I have prepared, I have /boot on sda1, / on sda2, and LUKS+LVM (containing swap and /home) on sda3.

Any other idea?

Thanks again.

Last edited by n0rthst4r; 07-09-2019 at 08:18 AM.
 
Old 07-09-2019, 08:38 AM   #4
Turbocapitalist
Senior Member
 
Registered: Apr 2005
Distribution: Linux Mint, Devuan, OpenBSD
Posts: 4,173
Blog Entries: 3

Rep: Reputation: 2064Reputation: 2064Reputation: 2064Reputation: 2064Reputation: 2064Reputation: 2064Reputation: 2064Reputation: 2064Reputation: 2064Reputation: 2064Reputation: 2064
Quote:
Originally Posted by n0rthst4r View Post
I don't know if I can use keys. I suppose you mean adding private SSH keys to the point-of-sale so it only accepts SSH from the support computer, don't you? But I am afraid that is almost impossible since we have a lot, like three hundred or something like that.
I've found very little material about SSH certificates, but what I have been able to find suggests they might be useful in the situation you describe. They're not widely known but rumor is that they are commonly used at scale in most of the larger companies around. So only 300 or so units would not be a problem there.
 
Old 07-09-2019, 12:05 PM   #5
n0rthst4r
LQ Newbie
 
Registered: May 2019
Location: Spain
Distribution: Ubuntu mostly
Posts: 11

Original Poster
Rep: Reputation: Disabled
Awesome article, and so well explained, seems easy.
We have already in the past prepared scripts for updating them remotely but not this kind of stuff.

Thanks for the info.
 
Old 07-09-2019, 12:31 PM   #6
TB0ne
LQ Guru
 
Registered: Jul 2003
Location: Birmingham, Alabama
Distribution: SuSE, RedHat, Slack,CentOS
Posts: 21,962

Rep: Reputation: 5827Reputation: 5827Reputation: 5827Reputation: 5827Reputation: 5827Reputation: 5827Reputation: 5827Reputation: 5827Reputation: 5827Reputation: 5827Reputation: 5827
Given your situation, I'm wondering why you're going this route. Wouldn't it be simpler to 'hide' an admin-level menu somewhere on the device itself, that performs those functions? Since it's a POS device, it probably has a touch screen or some sort of input device. A long time ago, I worked somewhere that had a text-based (well, EVERYTHING was text based back then...) system, but if you put in a ";99;", it would take you to an admin screen, to perform some admin-type tasks. This sounds like the same sort of thing you're wanting to accomplish. Should be easy enough to modify the 'home screen' code to listen for some sort of unique key combo/input sequence.

You could keep ALL your scripts on the device itself, no need for SSH, shipping other units, etc. If they break the device itself, they've already got a LOT more than a backup script anyway.
 
Old 07-10-2019, 01:00 AM   #7
n0rthst4r
LQ Newbie
 
Registered: May 2019
Location: Spain
Distribution: Ubuntu mostly
Posts: 11

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by TB0ne View Post
Given your situation, I'm wondering why you're going this route. Wouldn't it be simpler to 'hide' an admin-level menu somewhere on the device itself, that performs those functions? Since it's a POS device, it probably has a touch screen or some sort of input device. A long time ago, I worked somewhere that had a text-based (well, EVERYTHING was text based back then...) system, but if you put in a ";99;", it would take you to an admin screen, to perform some admin-type tasks. This sounds like the same sort of thing you're wanting to accomplish. Should be easy enough to modify the 'home screen' code to listen for some sort of unique key combo/input sequence.

You could keep ALL your scripts on the device itself, no need for SSH, shipping other units, etc. If they break the device itself, they've already got a LOT more than a backup script anyway.
Yes. I also suggested that, but that would be on engineers side and they are busy doing whatever else. So I decided to try on my own.


Besides, I have just found, accidentally, a security hole that I didn't expected, emergency mode. While I was playing around, Ubuntu booted to emergency mode and it didn't ask for a root password. There it was, almighty unprotected root user. Is that the default behaviour?? I just remember ending up there once or twice long time ago and my knowledge of Linux was so little that I decided to start over, but I think I was asked for a password; even Windows does.
Setting a password for root made the trick anyway.

Last edited by n0rthst4r; 07-10-2019 at 02:10 AM.
 
Old 07-10-2019, 07:02 AM   #8
TB0ne
LQ Guru
 
Registered: Jul 2003
Location: Birmingham, Alabama
Distribution: SuSE, RedHat, Slack,CentOS
Posts: 21,962

Rep: Reputation: 5827Reputation: 5827Reputation: 5827Reputation: 5827Reputation: 5827Reputation: 5827Reputation: 5827Reputation: 5827Reputation: 5827Reputation: 5827Reputation: 5827
Quote:
Originally Posted by n0rthst4r View Post
Yes. I also suggested that, but that would be on engineers side and they are busy doing whatever else. So I decided to try on my own.

Besides, I have just found, accidentally, a security hole that I didn't expected, emergency mode. While I was playing around, Ubuntu booted to emergency mode and it didn't ask for a root password. There it was, almighty unprotected root user. Is that the default behaviour?? I just remember ending up there once or twice long time ago and my knowledge of Linux was so little that I decided to start over, but I think I was asked for a password; even Windows does.
Setting a password for root made the trick anyway.
Yep...booting to single-user mode drops you to a default root shell. And if your device has a USB port, be aware that they may also be able to boot from a USB stick, which ALSO gives them their own way in.

There aren't going to be any 100% safe, secure methods of doing this. Personally, I'd make peace with the fact that someone can look at your shell scripts, and not waste a ton of time on this.
 
Old 07-10-2019, 09:17 AM   #9
Turbocapitalist
Senior Member
 
Registered: Apr 2005
Distribution: Linux Mint, Devuan, OpenBSD
Posts: 4,173
Blog Entries: 3

Rep: Reputation: 2064Reputation: 2064Reputation: 2064Reputation: 2064Reputation: 2064Reputation: 2064Reputation: 2064Reputation: 2064Reputation: 2064Reputation: 2064Reputation: 2064
Yeah, if they have physical access it is pretty much game over. Even the OpenBSD developers gave up on that a long time ago. However, if you still want to try to raise the bar a little, you can lock down GRUB2 and UEFI (formerly BIOS) and thus raise the bar a little. Just don't lock yourself out.
 
Old 07-10-2019, 09:34 AM   #10
TB0ne
LQ Guru
 
Registered: Jul 2003
Location: Birmingham, Alabama
Distribution: SuSE, RedHat, Slack,CentOS
Posts: 21,962

Rep: Reputation: 5827Reputation: 5827Reputation: 5827Reputation: 5827Reputation: 5827Reputation: 5827Reputation: 5827Reputation: 5827Reputation: 5827Reputation: 5827Reputation: 5827
Quote:
Originally Posted by Turbocapitalist View Post
Yeah, if they have physical access it is pretty much game over. Even the OpenBSD developers gave up on that a long time ago. However, if you still want to try to raise the bar a little, you can lock down GRUB2 and UEFI (formerly BIOS) and thus raise the bar a little. Just don't lock yourself out.
And I'll tack on "Don't make it a pain for yourself, either". Nothing spells fun like spending 4 hours at dark-O-thirty in the morning to try to fix a 5 minute problem, because of the 97 things you have to do first to GET to the system.

Reminds me of when blade servers came out, and I'd catch grief for always wanting systems with some sort of physical console. "You can always just get a web browser! We have a console from anywhere!!". Right up until they had a Java or browser-version issue, and had to spend hours looking for a machine that was old, but not TOO old, just to be able to log in.
 
Old 07-10-2019, 09:43 AM   #11
dc.901
Member
 
Registered: Aug 2018
Location: Atlanta, GA - USA
Distribution: CentOS 6-7; SuSE 8-12
Posts: 599

Rep: Reputation: 174Reputation: 174
The more I read this thread the more I am thinking you need to use a programming language that has to be compiled, so you only have to distribute binary files. With this method, there is no way anyone can look inside your code.
 
Old 07-10-2019, 07:38 PM   #12
wpeckham
Senior Member
 
Registered: Apr 2010
Location: Continental USA
Distribution: Debian, Ubuntu, Fedora, RedHat, DSL, Puppy, CentOS, Knoppix, Mint-DE, Sparky, Vsido, tinycore, Q4OS
Posts: 3,046

Rep: Reputation: 1332Reputation: 1332Reputation: 1332Reputation: 1332Reputation: 1332Reputation: 1332Reputation: 1332Reputation: 1332Reputation: 1332Reputation: 1332
Quote:
Originally Posted by dc.901 View Post
The more I read this thread the more I am thinking you need to use a programming language that has to be compiled, so you only have to distribute binary files. With this method, there is no way anyone can look inside your code.
NO, actually there are many of us here that can search binary files for strings or decompile packages into human readable source. It is not a foolproof solution, but the user has to WANT the information and know or study enough to figure out how to get it out. How dedicated to breaking security do you think these people are? A compiled solution makes things better, but not perfect. I am not sure perfect is an attainable goal in this case.

The target is security that is "good enough" for these scripts.

Last edited by wpeckham; 07-10-2019 at 07:41 PM.
 
Old 07-11-2019, 07:24 AM   #13
pan64
LQ Guru
 
Registered: Mar 2012
Location: Hungary
Distribution: debian/ubuntu/suse ...
Posts: 13,098

Rep: Reputation: 4143Reputation: 4143Reputation: 4143Reputation: 4143Reputation: 4143Reputation: 4143Reputation: 4143Reputation: 4143Reputation: 4143Reputation: 4143Reputation: 4143
Quote:
Originally Posted by wpeckham View Post
NO, actually there are many of us here that can search binary files for strings or decompile packages into human readable source. It is not a foolproof solution, but the user has to WANT the information and know or study enough to figure out how to get it out. How dedicated to breaking security do you think these people are? A compiled solution makes things better, but not perfect. I am not sure perfect is an attainable goal in this case.

The target is security that is "good enough" for these scripts.
just remember, anyhow the protected data has to be used, so it will be available somewhere in memory or even in a file.
 
Old 07-11-2019, 09:11 PM   #14
JJJCR
Senior Member
 
Registered: Apr 2010
Posts: 1,642

Rep: Reputation: 277Reputation: 277Reputation: 277
check out this link: https://tecadmin.net/create-binary-f...-shell-script/

Site says can compile the shell script to binary
 
Old 07-12-2019, 02:20 AM   #15
n0rthst4r
LQ Newbie
 
Registered: May 2019
Location: Spain
Distribution: Ubuntu mostly
Posts: 11

Original Poster
Rep: Reputation: Disabled
Ok, sorry for such a delayed replay.

Thank you all.

I guess they will be pretty busy to waste time in trying to break all this.

For me, this is being a challenge and I am enjoying every second I dedicate to the scripts and the system, it is so rewarding for me when I have success.

So, the thing right now is I am using blind-bash and LUKS autodecryption at boot and that would be enough, but I would like to go a step further and try to hide /etc/crypttab and make harder to figure out how to decrypt LUKS volume if they boot from USB or whatever. I have tried to include it inside initramfs and deleting it from the real /etc folder but it fails. You all think doing this is something stupid, don't you? I don't really know how initramfs works. I just thought that, being already copied to initramfs, I could just delete it and it will be available at next boot. It is actually inside initramfs, I have checked, but after rebooting the setup is broken. Do you think you can help me with that?

Learning to code in some compiled language is something I am already doing but I am kind of in a hurry and it will take me a long time and besides, that won't protect the thing 100%. It will be just a bit harder. Binaries can be easily torn out too, can't they?

I will give a try to the way JJJCR suggests, just for my own knowledge, it sounds promising.

Thank you all again!
 
  


Reply

Tags
encryption, scripts, security


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Mint 18 Full disk encryption VS Veracrypt Full Disk encryption: Help a Noob Decide Please ! APeacefulRig Linux - Security 2 11-11-2016 08:10 AM
[SOLVED] Non-system partition encryption versus container-file encryption of equal size Ulysses_ Linux - Security 13 07-17-2015 07:38 PM
LXer: Python Scripts as a Replacement for Bash Utility Scripts LXer Syndicated Linux News 1 01-17-2013 08:08 AM
Linux password encryption and data encryption Tux-Slack Programming 4 06-20-2007 06:46 AM
Mandrake 9.0 Wireless Works without encryption.. does not with encryption topcat Linux - Wireless Networking 3 05-04-2003 08:47 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Security

All times are GMT -5. The time now is 06:55 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration