1

The premise: on a Linux workstation I regularly download and use various software, let's say Perl or Nodejs modules. When I use them they run on the machine with me as the owner and can do whatever I can in my home directory, so they can access and steal (send over the network) my keys etc.

That thought has been gnawing me for years, now I finally found time to learn SELinux to deal with the problem. But as I was learning SELinux, it occurred to me, that someone might have already created some modules for applications which use those sensitive data, let's say a SELinux policy module for gnupg to restrict access to the gpg keys only for that app. But it seems not to be the case. So that is why I started to doubt the whole idea. I searched the web for "linux process home directory steal files" and similar queries and results were generally about physical theft. It's very unlikely, that I'm the only one who thought about this.

So my first question is whether the premise is true?

If it is, then what are optimal options to deal with this? Currently I'm going to try to customize the targeted SELinux policy to allow access to those sensitive files only to a limited set of processes and possibly limit network access on the application basis.

I would need to customize the targeted policy, since it seems to allow the unconfined_t domain to access both user_home_t and gpg_secret_t, since gpg_secret_t is part of the user_home_type attribute and the policy allows full access to it:

$sesearch -t gpg_secret_t -A
…
allow unconfined_t user_home_type:file { read write … }
Dmitry Koroliov
  • 281
  • 1
  • 7
  • 1
    Could you please explain why you need to run untrusted code as the normal user in the first place? Why not use existing and simple separation mechanism like running such code as a different user? For me this looks like attempting to solve the problem the hard instead of the simple way but maybe I'm missing context which would make it clear that the simple way is not an option. – Steffen Ullrich Jun 06 '19 at 20:56
  • @SteffenUllrich sorry if this sounds stupid, but how can I run that code as a different user? Should I create a dummy user and switch to it in bash like `su dummy` and make all necessary stuff with its userid? That has never occurred to me. The downside of that approach would be, that I may accidentally still forget to switch user every so often – Dmitry Koroliov Jun 06 '19 at 21:08
  • @SteffenUllrich or should I have copies of, say, the 'perl', 'nodejs' binaries, owned by that dummy user, so that they are always run as that dummy user? – Dmitry Koroliov Jun 06 '19 at 21:11
  • @SteffenUllrich thank you for the suggestion. I found, that I can use the 'su -c "./script" dummy' approach. Can be a good temporary shortcut – Dmitry Koroliov Jun 06 '19 at 21:41
  • 2
    The separation you get if you run untrusted code as a different user is even harder compared to what you get when just protecting critical files. While untrusted code might not be able to access the private keys from gnupg the code might still run gnupg and use it to sign something in your name. Also, you could just create a different user on the system and `ssh` into it to do more complex things than just running a single command. – Steffen Ullrich Jun 07 '19 at 03:40
  • 2
    Be careful su'ing to an untrusted user. A TTY pushback attack could allow the other user to run commands as your user. – multithr3at3d Jun 08 '19 at 16:24

1 Answers1

1

Currently I ended up without SELinux in this case.

Instead I set up a separate user account, in which home directory I store the primary key and switch to that account if I need to sign something or decrypt (one can generate a subkey to use under his general account). Despite SELinux unconfined processes being run with root privileges still can access the key storage, I generally don't run untrusted code as root, so this should be a good mitigation.

Also I completely forbade network access to that account, using netfilter meta skuid expression.

Third, regularly review audit reports for failed authorizations, logins etc. through aureport.

Some SELinux protection wouldn't be redundant at all, but since I don't know currently the syntax of SELinux policies etc., I have to depend 100% on the distro provider's policy.

With all that, I can summarise, that on a personal computer it should be more than enough:

  • to use separate Linux accounts for access to sensitive data
  • to restrict network access to a required minimum
  • to review audit reports
Dmitry Koroliov
  • 281
  • 1
  • 7