Hey OSMC-Community, I’m a Kodi user since the first Raspberry Pi models have been released in 2012. After 10 years with a couple of device iterations, I finally bought a vero4k+ a couple of weeks ago. I really appreciate your idea of an open (‘fully owned’) and long-time supported device and am really impressed by the performance of this hardware and its superb software support in OSMC.
The main reason for this post: I’d like to use the vero4k+ as a TV streaming client (via waipu.tv) in our holiday flat that we rent to tourists. Generally the vero4k+ works excellent for this purpose.
What I’d like to know: Is there any hardening guide for the vero4k+ or OSMC in General? In Kodi I’ve created a specific Profile (different from master) with limited access to the main settings and an additional 6-digit-PIN code for access, but I’d like to harden it a bit more on OS level. E.g. I’d like to deny access to the USB Ports, disable any access to the local console and the OS.
More info / Comparison vero4k+ and Roku 4k
An additional info: I bought this device as an alternative to a trashy ‘Roku 4k’ which is advertised as an ‘intuitive’ Linux device for streaming (Spoiler Alert: It isn’t at all!) - I thought a commercial device would be an easy solution for my holiday flat purpose - to prevent anyone making the same mistakes: Save the money for the Roku devices and use a Kodi distribution of your choice! It works much better out of the box and is much more intuitive.
Hi
This is an interesting use case and something I’ve been looking in to recently but I don’t have any solid idea for how to implement it yet.
We could use something like dm-verity so we have an ephemeral filesystem which is reset on a power cycle.
You say you’d like to disable access to USB etc, it’s possible. But I’m not sure how you’d re-enable support.
I think you will probably get away with locking things down in Kodi and changing the osmc password so that a user can’t login to the system.
I already heard about your outstanding support but even with that in mind I didn’t expect such a detailed answer from the boss himself in less than five minutes. Well done and thanks a lot!
Nice idea, I googled that and it sounds like an excellent solution for that use case as you can reset the device with a simple reboot. With dm-verity implemented, you won’t need any restrictions according USB-Ports as all change are none-persistent. Of course all guest-accessible devices have to be in a specific/restricted network segment so that even temporarily compromised devices will not harm others.
Got your point, I thought about a simple re-installation of the OS but of course this needs an active USB port.
In General I’d like to keep the ssh access enabled for support and maintenance purposes but limit that to key-based access only (combined with an ip access list maybe). It should be a sufficient hardening measure on that side for a simple entertainment device. With that in mind: Do you think re-enabling the USB access (via SSH) would be feasible?
Another idea
I use a Raspi4 as a kind of a ‘home automation screen’. As my family (mainly the kids) loves to pull plugs, I decided to lock the filesystem via overlay-filesystem. Would this be easily possible with the vero? It’s an comparable idea: Preventing the filesystem from (unwanted) changes and reset any changes with a reboot. Additionally, it defines a ‘definitely booting’ setup which is safe from these unexpected power losses.
The thing is - if there’s physical access to the device, there’s always going to be a vector to attack the device.
You probably won’t have malicious actors but you may want to protect the device against accidental breakage.
I wouldn’t disable USB ports - you’ll need one for the OSMC remote, but rather disable the udisks service. This will stop users from being able to plug in and mount external media.
You could use an overlay approach and I’ve looked in to this before, but I didn’t work out how we would handle updates yet. You would need to pin your system to a specific version of OSMC - which could mean you would be missing out on important updates.
We have overlayfs support enabled in the kernel, so you can use this approach.
1 Like
Would disabling udisks-glue work by essentially removing any auto-mounting of USB drives?
Curious why you would need to disable USB? Since you can’t get to a shell via the OSMC GUI, there’s really nothing they could do by inserting their own USB drive, etc. The vero4k won’t boot from a USB drive unless you’re using an OSMC restore image, for example.
You could use osmc.skin to basically remove all the current Kodi menu items for a given profile, and just set up a menu that runs the specific addons you want them to have access to. This would remove access to settings, etc.
Instead of requiring a PIN, you could write a script that would modify /home/osmc/.kodi/userdata/profiles.xml to add/remove profiles (Master, private users, etc.), leaving only a GUEST profile. When you want access to the “private” profiles log into the box via ssh and enable those profiles, but then disable them again when you’re done.
Goodluck!
You could connect a keyboard to stop OSMC from booting into Kodi
Hadn’t thought of that – but with physical access you can do many things.
Does @Shizzle just want to protect a device against people messing around or against malicious attacks such as credential theft?
I actually tried that recently, and neither holding space nor CTL did anything during boot. I had to get a rescue boot image from @sam_nazarko to get in.
Works here if you click it when the blue OSMC screen comes up.
I tried single press, and holding down during the entire boot-up (of both space and CTL), and neither took me to a recovery shell. 
I had to boot from a USB flash with the recovery image sam gave me, and then use SSH to access a shell to mount my emmc so I could undo an edit I made that had caused my systemd start-up to hang.
To be honest: I didn’t create all possible scenarios yet. As the target audience is mainly a tourist, everything might be possible. First of all I’d like to prevent an accidentally bricked device that leads to a ‘support case’ like ‘The TV in your flat is no longer working, please fix this for us!’ So a defined boot environment (like with overlay-fs or dm-verity) seems desirable in case someone crashed the vero.
According credential thefts, I’m not that concerned because there simply aren’t any! For waipu.tv I use device registration that relies IMHO on a local device cookie. Web access, remote control and all other kodi services should be disabled as they are not needed by my customers, ssh is protected via key-based access only. Additionally, I’d like to use e.g. ufw to restrict access to the device to prevent access via crosslink.
Another malicious attack could be a virus or worm that was copied to the device via USB and that’s why I’d like to disable USB and the µSD card reader - just in case.
I know but I’d like to mitigate that as good as possible. Of course in a very hard case of paranoia you should assume the device to be compromised - but an open source set top box for my holiday flat would be my dream and therefore I fight against my security paranoia and try to make it possible.
I’d prefer CEC with the original TV’s remote because you can switch the TV on and off and can control OSMC with that (more consistent user experience). So no need for the OSMC remote 
And with USB enabled, you could still use a keyboard or mouse.
May I ask what you’ve got in mind? I think about the following:
- Use a keyboard to gain console access during boot (I think it’s pressing CTRL or so) or in runtime
- Use a mass storage device to transfer malicious files to the device
- Use a keyboard to enter some hidden commands/shortcuts (in the ALT+PrntScr+REISUB manner)
I’m really enjoying the discussion here and would like to thank you all for your great input! 
In the meanwhile I’m also enjoying the vero4k+ on my private TV 
and thinking about using OSMC with an old Pi3 in the flat. That should be enough horsepower for web TV streaming. 
If your not going to go to physically securing the device it seems to me that maybe the simplest solution is just use your old RPi with a small SD card and make an image and clone that to another SD once it is configured. If a guest has an issue just tell them where the backup SD is and have them swap it. You can always just reimage the SD’s when needed without any real effort. I would imagine if your going to maintain remote access you could also keep a copy of ~/.kodi on the SD and at any point SSH in, stop mediacenter, delete current userdata, copy the copy, and start mediacenter again. As long as you omit the “Thumbnails” folder from the copy the userdata should be fairly small.
As for locking down inside Kodi, why put a pin on the extra profile? If you have hidden access to videos and the libraries and locked settings and what not why not just have it boot into the previously loaded profile so it by default just loads into where you want them to be? If they don’t have any easy access to change much why make them do any extra work. If someone is clever and inclined they can always mess with a device, but you can make it quick and easy to recover for the next person.
On a side note you can turn the TV on and off with the OSMC remote. If you configure the CEC settings to allow activating on start the home button on the remote will turn on the TV and switch inputs when you press it a couple times. When you are on the home screen you can hold down the home button and that will turn the TV off. Using the TV remote may be easier guest user type application though as that is not the most intuitive way to turn a TV on or off.
Okay, so if I wanted to protect the device given your scenario, I’d do as follows:
sudo systemctl disable udisks
sudo systemctl disable udisks-glue
sudo fw_setenv osmcfromsd "true"
sudo fw_setenv osmcfromusb "true"
passwd osmc
This disables the ability for udisks to mount drives; the system cannot be reinstalled via USB or SD card and the command line is not accessible unless the password is known. You can then enable key based authentication via SSH as you wanted remote access.
Users then have two physical attack vectors:
- The SDIO interface, using a proprietary AMLogic debug dongle.
- Opening the device and shorting eMMC pins and performing a low level format.
This isn’t your typical attack vector for a holiday let
They could also upload a Python script from the internet or a repository and elevate privileges. Again – I think this is unlikely.
We are exploring remote management in the future – i.e. backup; restore; snapshot. But this is a long way off yet.
If credential theft isn’t a concern – I think this is good enough.
Cheers
Sam
1 Like
I was thinking about your proposal over the last 14 days and it seems to fit my needs. Of course, there is still the risk of someone opening (cracking) the case but in General I don’t think the average guest will not carry it’s soldering iron for hacking purposes
Once again, I’d like to thank you so much for your effort. I’m definitely a happy customer.
Respectfully
René
PS: In the meanwhile, Roku enabled the waipu app but the user interface is still “demanding”.
If someone has physical access to the device, and does this, then I think you have other things to worry about.
The services you use probably would inform you of a ‘new login’ from another region or IP if they left and tried to steal your credentials.
Let me know if there’s anything further we can help with
Sam
I definitely will, but currently I’m completely satisfied 