Use your smart-phone as webcam and keep enjoying enhanced security as well

Use your smart-phone as webcam and keep enjoying enhanced security as well

What I want to do

I don’t want to buy a webcam for my computer. I have a smart-phone with both front and rear cameras. Can’t I use it as webcam?

Are you interested in Enhanced Security?

Maybe you are not interested in using your smart-phone as webcam.

But you may be interested in Enhanced Security instead.

If you are, keep reading because I’m going to tell you about SELinux, an additional level of security Linux servers, and desktops, enjoy.

The environment

The scenery where our troubleshooting is going to happen is a Linux Fedora desktop computer.

It comes with SELinux installed and running by default.

Precisely it’s Fedora 25. It’s using KDE Plasma as desktop environment. The desktop environment is irrelevant to our problem.

Droidcam

Droidcam is both an Android application and a Linux one. On the Linux side, Droidcam is written in C language and uses GTK as toolkit to create user interfaces. It can be used from the command line as well.

You find the source code here: https://github.com/aramg/droidcam/tree/master/linux.

You install and run Droidcam on Linux and do the same on your Android smartphone. It’s simple, you just tell the Linux application what ip address it can find the smart-phone at.

Droidcam uses port 4747. You may have to fix problems caused by firewalls if, like me, you have a firewall on your computer.

SELinux

SELinux adds security checks to your Linux computer. It makes more difficult for malware to infect the system. Linux is well-known for better security. SELinux adds even more security by isolating processes so that they don’t harm the system.

Why was Droidcam a problem?

You don’t find Droidcam in standard software repository. I downloaded it from https://www.dev47apps.com/files/600/droidcam-64bit.tar.bz2.

There is an ‘install’ script to run. It produces two modules the operating system will load when starting.

The problem was that SELinux prevented the modules from starting complaining about lack of permission.

I was getting these errors:

  1. Aug 12 07:31:58 localhost.localdomain systemd-modules-load[535]: Failed to insert ‘videodev’: Permission denied

  2. Aug 12 07:31:58 localhost.localdomain systemd-modules-load[535]: Failed to insert ‘v4l2loopback_dc’: Permission denied

When you see this sort of errors, you may not think about SELinux. You think that there may be a common permission problem related to user permissions. That’s why it can be difficult to troubleshoot.

Disabling SELinux

To see if SELinux is a problem, you first disable it.

You edit the file /etc/selinux/config where you set SELINUX=disabled.

Done this, the problem disappeared. But you are left with no Enhanced Security.

Using the audit log

SELinux registers every permission violation in a log called the audit log. You find it at this location: /var/log/audit.

In this case, our permission problem was logged in this way:

  1. type=AVC msg=audit(1502557651.920:115): avc:  denied  { module_load } for  pid=1028 comm=”systemd-modules” scontext=system_u:system_r:systemd_modules_load_t:s0

  2. tcontext=system_u:system_r:systemd_modules_load_t:s0 tclass=system permissive=0

Now what?

Do I have to learn about SELinux now? Do I need to learn how to configure SELinux permissions? Do I need to read long instructions and manuals?

Happily no, I don’t have to.

SELinux comes with two very handy tools.

The first one is audit2why. You feed it with the error message and it tells you what’s the problem.

Let’s see

  1. [esantanche@localhost]~% echo “type=AVC msg=audit(1502557651.920:115): avc:  denied  { module_load } for  pid=1028 comm=”systemd-modules” scontext=system_u:system_r:systemd_modules_load_t:s0 tcontext=system_u:system_r:systemd_modules_load_t:s0 tclass=system permissive=0″ | audit2why

  2. type=AVC msg=audit(1502557651.920:115): avc:  denied  { module_load } for  pid=1028 comm=systemd-modules scontext=system_u:system_r:systemd_modules_load_t:s0 tcontext=system_u:system_r:systemd_modules_load_t:s0 tclass=system permissive=0

  3. Was caused by:

  4. Missing type enforcement (TE) allow rule.

  5. You can use audit2allow to generate a loadable module to allow this access.

  6. [esantanche@localhost]~%

The tool is telling us that a rule is missing. A rule that would allow the operation that has been denied, the latter being the loading operation of the module Droidcam installed.

We are also advised to use another tool to generate that rule. Just to add to confusion, SELinux calls its rules modules. But a SELinux module is about giving permissions whilst a kernel module is about performing tasks like managing a webcam.

The tool we need to use is audit2allow.

Here it is:

  1. [esantanche@localhost]~% echo “type=AVC msg=audit(1502557651.920:115): avc: denied { module_load } for pid=1028 comm=”systemd-modules” scontext=system_u:system_r:systemd_modules_load_t:s0 tcontext=system_u:system_r:systemd_modules_load_t:s0 tclass=system permissive=0″ | audit2allow -M module_load_policy

  2. ******************** IMPORTANT ***********************

  3. To make this policy package active, execute:

  4. semodule -i module_load_policy.pp

  5. [esantanche@localhost]~% sudo semodule -i module_load_policy.pp

The tool created the permission we need for Droidcam to work from the audit error above. No complicated configurations to do, no long manuals to learn. Just feed audit2allow with the error message and it will create a rule SELinux will use to allow Droidcam to work.

Just consider that SELinux calls its permission rules modules and this may be confusing.

Conclusion

When you get strange permission errors you can’t explain and you eventually, after long investigation, realise it’s SELinux causing them, you want to get rid of SELinux.

Why not just disable it? No mysterious permission errors any more.

There are cases, like this one, that you are doing strange installations. Droidcam is a bit special and creates kernel modules its own way.

Imagine that it was some malware installing modules. SELinux would have saved you from harm.

It’s better to keep SELinux up and running and enjoy the enhanced security it offers.

Happily it provides tools that make you job easier and you don’t have to learn complicated ways to configure permission rules.