Android Backstage, a podcast by and for Android developers. Hosted by developers from the Android engineering team, this show covers topics of interest to Android programmers, with in-depth discussions and interviews with engineers on the Android team at Google. Subscribe to Android Developers YouTube → https://goo.gle/AndroidDevs
…
continue reading
Player FM - Internet Radio Done Right
26 subscribers
Checked 3d ago
Added nine years ago
Content provided by HPR Volunteer and Hacker Public Radio. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by HPR Volunteer and Hacker Public Radio or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://ppacc.player.fm/legal.
Player FM - Podcast App
Go offline with the Player FM app!
Go offline with the Player FM app!
HPR4328: Use SELinux the easy way
Manage episode 469681612 series 108988
Content provided by HPR Volunteer and Hacker Public Radio. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by HPR Volunteer and Hacker Public Radio or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://ppacc.player.fm/legal.
The most basic security toggle on your Linux computer is the setenforce command. Using just a single setenforce instruction, you can configure SELinux to allow a violation it would normally prevent. There are two states: Enabled and Permissive. By default, SELinux is Enabled (also represented as 1 when using Boolean values). To set SELinux to permissive mode: $ sudo setenforce Permissive When something works in Permissive mode, you've successfully identified the symptom, but you haven't fixed the problem yet. Activate Enforcing mode again: $ sudo setenforce Enforcing Check the status of SELinux You can check the state of SELinux at any time using the sestatus command: $ sestatus SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: enforcing [...] Look at labels and contexts If you have a running Linux system, then you have an example of what SELinux requires for normal operation. You don't have to learn about security contexts or memorize labels. For most anything you try to do on your computer, there are likely already files doing something similar. Use those files as templates. You can look at the security labels of any file you have access to by using the -Z (that's a capital Z) option of ls: $ touch hellotouch hello.txt $ ls -Z hello.txt unconfined_u:object_r:user_home_t:s0 hello An empty file created by a user in the user's own home directory has, as you might expect, a very specific security profile. Even with the executable bit set, that file would not be permitted to run as a systemwide service. It just doesn't have the correct security context. If you use an ll alias, try adding the -Z option to its option list so you get used to seeing SELinux labels. The more you see what labels exist on your system, and how they relate to various system roles, you're more likely to recognize when they're wrong. Copy contexts Suppose you were developing a custom SELinux service for your laptop. You've written a shell script, a service file, and you've placed them in the appropriate system locations. You're also careful to set ownership and permissions correctly. But no matter what you do, you get errors when attempting to start the service. You suspect that SELinux might be preventing an unrecognized service from running. That would normally be appreciated, but in this case you want to make an exception. First, confirm that the service runs successfully with SELinux in Permissive mode: $ sudo setenforce Permissive $ sestatus | grep Current Current mode: permissive $ sudo systemctl start hello.service || echo "fail" $ $ sudo setenforce Enforcing Then look at the files you've created using the -Z and compare them with other files that you know to be working properly. Note the differences: $ ls -Z /usr/lib/systemd/system/hello.service unconfined_u:object_r:systemd_unit_file_t:s0 $ ls -Z /usr/lib/systemd/system/rdisc.service system_u:object_r:rdisc_unit_file_t:s0 The working service (rdisc.service in this example, chosen at random) features the system_u label as well as a special rdisc_unit_file_t label. Suppose you know from previous experience with ls -Z that a common SELinux label for systemd serv
…
continue reading
4395 episodes
Manage episode 469681612 series 108988
Content provided by HPR Volunteer and Hacker Public Radio. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by HPR Volunteer and Hacker Public Radio or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://ppacc.player.fm/legal.
The most basic security toggle on your Linux computer is the setenforce command. Using just a single setenforce instruction, you can configure SELinux to allow a violation it would normally prevent. There are two states: Enabled and Permissive. By default, SELinux is Enabled (also represented as 1 when using Boolean values). To set SELinux to permissive mode: $ sudo setenforce Permissive When something works in Permissive mode, you've successfully identified the symptom, but you haven't fixed the problem yet. Activate Enforcing mode again: $ sudo setenforce Enforcing Check the status of SELinux You can check the state of SELinux at any time using the sestatus command: $ sestatus SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: enforcing [...] Look at labels and contexts If you have a running Linux system, then you have an example of what SELinux requires for normal operation. You don't have to learn about security contexts or memorize labels. For most anything you try to do on your computer, there are likely already files doing something similar. Use those files as templates. You can look at the security labels of any file you have access to by using the -Z (that's a capital Z) option of ls: $ touch hellotouch hello.txt $ ls -Z hello.txt unconfined_u:object_r:user_home_t:s0 hello An empty file created by a user in the user's own home directory has, as you might expect, a very specific security profile. Even with the executable bit set, that file would not be permitted to run as a systemwide service. It just doesn't have the correct security context. If you use an ll alias, try adding the -Z option to its option list so you get used to seeing SELinux labels. The more you see what labels exist on your system, and how they relate to various system roles, you're more likely to recognize when they're wrong. Copy contexts Suppose you were developing a custom SELinux service for your laptop. You've written a shell script, a service file, and you've placed them in the appropriate system locations. You're also careful to set ownership and permissions correctly. But no matter what you do, you get errors when attempting to start the service. You suspect that SELinux might be preventing an unrecognized service from running. That would normally be appreciated, but in this case you want to make an exception. First, confirm that the service runs successfully with SELinux in Permissive mode: $ sudo setenforce Permissive $ sestatus | grep Current Current mode: permissive $ sudo systemctl start hello.service || echo "fail" $ $ sudo setenforce Enforcing Then look at the files you've created using the -Z and compare them with other files that you know to be working properly. Note the differences: $ ls -Z /usr/lib/systemd/system/hello.service unconfined_u:object_r:systemd_unit_file_t:s0 $ ls -Z /usr/lib/systemd/system/rdisc.service system_u:object_r:rdisc_unit_file_t:s0 The working service (rdisc.service in this example, chosen at random) features the system_u label as well as a special rdisc_unit_file_t label. Suppose you know from previous experience with ls -Z that a common SELinux label for systemd serv
…
continue reading
4395 episodes
All episodes
×Welcome to Player FM!
Player FM is scanning the web for high-quality podcasts for you to enjoy right now. It's the best podcast app and works on Android, iPhone, and the web. Signup to sync subscriptions across devices.