Author Topic: Whonix AppArmor Profiles Development Discussion  (Read 28156 times)

Patrick

  • a maintainer of Whonix
  • Administrator
  • *****
  • Posts: 3398
  • (adrelanos)
    • View Profile
    • Patrick Schleizer – Profile Page
Re: Join us testing new AppArmor Profiles! (Whonix Security Hardening)
« Reply #75 on: March 11, 2014, 11:40:11 pm »
In https://www.whonix.org/w/index.php?title=AppArmor/Whonixcheck&oldid=6794&diff=cur you reintroduced the usr / user error.

Also whonixcheck needs read access to /home/user/tor-browser_en-US/Docs/sources/versions because it checks Tor Browser's version.

timesync / sdwdate: It depends. On boot, sdwdate starts on its own (by /etc/init.d/sdwdate). One could have timesync uninstalled and sdwdate would still work. (I plan to make these two separate packages. When timesync is manually started, it restarts and monitors sdwdate, hence the confusion. Also since sdwdate dispatches parts of timesync if available. Perhaps I must clean up the implementation, but it works fine for now.) However, /usr/bin/sdwdate needs a profile upon start.

(If you don't believe me or want to test it, edit /usr/bin/sdwdate and add a "echo test > /home/user/sdwdatetest" below "#!/bin/bash". - I guess it would be able to do this unauthorized write.)

Since sdwdate is a deamon, I am not sure if we need to edit it's init script. For example the /etc/init.d/tor (you can look at it on Whonix-Gateway) has native support for AppArmor. I am not sure, if we would need to do this for sdwdate as well. Probably not. Probably a profile for /usr/bin/sdwdate would be sufficient (I guess AppArmor doesn't really care if an init script or user starts an application).
HOT: How to Ask Smart Questions | How to Report Bugs Effectively
Impressum | Datenschutzerklärung | Haftungsausschluss
If Whonix (g+) is useful to you, please consider a reoccurring donation so I (e-mail) (gpg) (g+) can work full time on Whonix.
Need more attention? Get Professional Support!

troubadour

  • Moderator
  • *****
  • Posts: 594
    • View Profile
Re: Join us testing new AppArmor Profiles! (Whonix Security Hardening)
« Reply #76 on: March 12, 2014, 06:28:58 pm »
Quote
In https://www.whonix.org/w/index.php?title=AppArmor/Whonixcheck&oldid=6794&diff=cur you reintroduced the usr / user error.

Also whonixcheck needs read access to /home/user/tor-browser_en-US/Docs/sources/versions because it checks Tor Browser's version.

Added  /home/user/tor-browser_en-US/Docs/sources/versions. There was  /home/user/tor-browser_en-US/Docs/version already in the profile. A bit confusing. I'll test it with whonixcheck --verbose to make sure.

Quote
timesync / sdwdate: It depends. On boot, sdwdate starts on its own (by /etc/init.d/sdwdate). One could have timesync uninstalled and sdwdate would still work. (I plan to make these two separate packages. When timesync is manually started, it restarts and monitors sdwdate, hence the confusion. Also since sdwdate dispatches parts of timesync if available. Perhaps I must clean up the implementation, but it works fine for now.) However, /usr/bin/sdwdate needs a profile upon start.

Added the profile for sdwdate. I first added 'USE_AA_EXEC="yes"' in '/etc/init.d/sdwdate', but since it starts as a deaemon at boot, it is not needed, it is automatically enforced.

I think I  mentioned it before. I the Gateway, system_tor in no longer confined since Whonix 8. Ran 'aa-enforce system_tor' and it still does not show in the list of enforced profiles. I did not take the time to check further. I will.

Patrick

  • a maintainer of Whonix
  • Administrator
  • *****
  • Posts: 3398
  • (adrelanos)
    • View Profile
    • Patrick Schleizer – Profile Page
Re: Join us testing new AppArmor Profiles! (Whonix Security Hardening)
« Reply #77 on: March 12, 2014, 06:49:53 pm »
I am running

Code: [Select]
tail -f /var/log/kern.log
Then make a few empty spaces by pressing enter a few times, then run whonixcheck --verbose.

This is what I am getting when I press "cancel" while it is running.

Code: [Select]
Mar 12 17:45:42 host kernel: [65686.174435] type=1400 audit(1394646342.124:82): apparmor="DENIED" operation="open" parent=11803 profile="/usr/bin/whonixcheck" name="/proc/tty/drivers" pid=14493 comm="ps" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
And I am also having apparmor-notifier installed, which will in KDE always flash a message once there is a new apparmor denied message.

This is what I get when running whonixcheck --verbose.

Code: [Select]
Mar 12 17:47:49 host kernel: [65813.172202] type=1400 audit(1394646469.128:84): apparmor="DENIED" operation="exec" parent=18608 profile="/usr/bin/whonixcheck" name="/usr/bin/whoami" pid=18610 comm="whonixcheck" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
Mar 12 17:47:49 host kernel: [65813.172202] type=1400 audit(1394646469.128:85): apparmor="DENIED" operation="open" parent=18608 profile="/usr/bin/whonixcheck" name="/usr/bin/whoami" pid=18610 comm="whonixcheck" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
Mar 12 17:48:20 host kernel: [65845.022025] type=1400 audit(1394646500.976:86): apparmor="DENIED" operation="exec" parent=24312 profile="/usr/bin/whonixcheck" name="/usr/bin/tr" pid=24314 comm="whonixcheck" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
Mar 12 17:48:20 host kernel: [65845.022044] type=1400 audit(1394646500.976:87): apparmor="DENIED" operation="open" parent=24312 profile="/usr/bin/whonixcheck" name="/usr/bin/tr" pid=24314 comm="whonixcheck" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
HOT: How to Ask Smart Questions | How to Report Bugs Effectively
Impressum | Datenschutzerklärung | Haftungsausschluss
If Whonix (g+) is useful to you, please consider a reoccurring donation so I (e-mail) (gpg) (g+) can work full time on Whonix.
Need more attention? Get Professional Support!

Patrick

  • a maintainer of Whonix
  • Administrator
  • *****
  • Posts: 3398
  • (adrelanos)
    • View Profile
    • Patrick Schleizer – Profile Page
Re: Join us testing new AppArmor Profiles! (Whonix Security Hardening)
« Reply #78 on: March 12, 2014, 07:21:15 pm »
Adding 'USE_AA_EXEC="yes"' to sdwdate's init script is most likely indeed not required. (FYI: 'USE_AA_EXEC="yes"' isn't a magic word. Just a standard shell script variable. It would require additional implementation to react depending on the contents of USE_AA_EXEC, you can see this in Tor's init script if you search that script for USE_AA_EXEC.)

When I am running "sudo service sdwdate restart", I am getting this.

Code: [Select]
Mar 12 17:51:17 host kernel: [66032.669869] type=1400 audit(1394646677.848:89): apparmor="DENIED" operation="capable" parent=29668 profile="/usr/bin/sdwdate" pid=29669 comm="sdwdate" capability=1  capname="dac_override"
Mar 12 17:51:58 host kernel: [66073.429962] type=1400 audit(1394646718.612:90): apparmor="DENIED" operation="file_mmap" parent=30019 profile="/usr/bin/sdwdate" name="/lib/i386-linux-gnu/security/pam_cap.so" pid=30030 comm="sudo" requested_mask="m" denied_mask="m" fsuid=0 ouid=0

Also sdwdate needs access to /usr/lib/whonix/curl_exit_codes.

Otherwise sdwdate seems functional.
HOT: How to Ask Smart Questions | How to Report Bugs Effectively
Impressum | Datenschutzerklärung | Haftungsausschluss
If Whonix (g+) is useful to you, please consider a reoccurring donation so I (e-mail) (gpg) (g+) can work full time on Whonix.
Need more attention? Get Professional Support!

troubadour

  • Moderator
  • *****
  • Posts: 594
    • View Profile
Re: Join us testing new AppArmor Profiles! (Whonix Security Hardening)
« Reply #79 on: March 12, 2014, 10:02:28 pm »
We are using the same testing setup ('sudo tail -f /var/log/kern.log', make a few spaces after updating/saving the profile and running 'sudo apparmor_parser -r profile_name', restart the package).

With 'whonixcheck --verbose', I could see  the message after pressing cancel, plus a few others denying /et/apparmor.d.

With sdwdate, I could not recreate the error after restarting the service. Strange, again, but it's not a surprise , I've been doing that the whole day (well, almost...).

Both profiles are updated. 

Patrick

  • a maintainer of Whonix
  • Administrator
  • *****
  • Posts: 3398
  • (adrelanos)
    • View Profile
    • Patrick Schleizer – Profile Page
Re: Join us testing new AppArmor Profiles! (Whonix Security Hardening)
« Reply #80 on: March 12, 2014, 11:39:41 pm »
No more denied messages.

Only issue I am experiencing is, when I run "sudo service sdwdate restart" with the sdwdate profile enabled, I don't see the timesync gui anymore. Maybe I see the gui but the progress meter doesn't move. Or the progress meter moves, but it doesn't close when it reached 100%. This doesn't happen when the sdwdate profile is disabled. Without any denied messages, any idea how to fix it?
HOT: How to Ask Smart Questions | How to Report Bugs Effectively
Impressum | Datenschutzerklärung | Haftungsausschluss
If Whonix (g+) is useful to you, please consider a reoccurring donation so I (e-mail) (gpg) (g+) can work full time on Whonix.
Need more attention? Get Professional Support!

troubadour

  • Moderator
  • *****
  • Posts: 594
    • View Profile
Re: Join us testing new AppArmor Profiles! (Whonix Security Hardening)
« Reply #81 on: March 13, 2014, 09:23:49 pm »
Some new denied messages with 'timesync --verbose'. The profile was updated.

I am still trying to find out why the gui is not showing with "sudo service sdwdate restart" when it is enforced. So far, I had not exactly the same symptoms as you have.

Patrick

  • a maintainer of Whonix
  • Administrator
  • *****
  • Posts: 3398
  • (adrelanos)
    • View Profile
    • Patrick Schleizer – Profile Page
Re: Join us testing new AppArmor Profiles! (Whonix Security Hardening)
« Reply #82 on: March 13, 2014, 10:09:24 pm »
I installed gnome-keyring, now I am getting this.

Code: [Select]
apparmor="DENIED" operation="file_mmap" parent=20243 profile="/usr/bin/timesync" name="/lib/security/pam_gnome_keyring.so" pid=20319 comm="sudo" requested_mask="m" denied_mask="m" fsuid=0 ouid=0
And this.

Code: [Select]
apparmor="DENIED" operation="file_mmap" parent=24365 profile="/usr/bin/whonixcheck" name="/lib/security/pam_gnome_keyring.so" pid=24430 comm="sudo" requested_mask="m" denied_mask="m" fsuid=0 ouid=0
HOT: How to Ask Smart Questions | How to Report Bugs Effectively
Impressum | Datenschutzerklärung | Haftungsausschluss
If Whonix (g+) is useful to you, please consider a reoccurring donation so I (e-mail) (gpg) (g+) can work full time on Whonix.
Need more attention? Get Professional Support!

troubadour

  • Moderator
  • *****
  • Posts: 594
    • View Profile
Re: Join us testing new AppArmor Profiles! (Whonix Security Hardening)
« Reply #83 on: March 13, 2014, 11:13:42 pm »
Normally, all the pam_xxx.so files are in /lib/i386-linux-gnu/security/. Added '/lib/security/* mr,' in sdwdate, time sync and whonixcheck, for safety.

Edit. With a typo i am correcting now...

troubadour

  • Moderator
  • *****
  • Posts: 594
    • View Profile
Re: Join us testing new AppArmor Profiles! (Whonix Security Hardening)
« Reply #84 on: March 13, 2014, 11:17:07 pm »
Correction done.

troubadour

  • Moderator
  • *****
  • Posts: 594
    • View Profile
Re: Join us testing new AppArmor Profiles! (Whonix Security Hardening)
« Reply #85 on: March 14, 2014, 09:06:19 am »
Quote
Only issue I am experiencing is, when I run "sudo service sdwdate restart" with the sdwdate profile enabled, I don't see the timesync gui anymore. Maybe I see the gui but the progress meter doesn't move. Or the progress meter moves, but it doesn't close when it reached 100%. This doesn't happen when the sdwdate profile is disabled. Without any denied messages, any idea how to fix it?

It seems that the normal behavior when running "sudo service sdwdate restart" is that it does not show the timsesync progress window. There is no reference to timesync in the sdwdate scripts in /etc/init.d/ or /usr/bin/, and sdwdate on its own does not display anything.

From the test I have done, when you start or reboot the workstation, the gui will show after "sudo service sdwdate restart"  only during the first sleeping period. After that, the gui is no longer displayed, regardless of the apparmor mode (enforce or disable). Just a guess, but it could have something to do with sdwdate running as a daemon and timesync on its own, in parallel. Aren't both basically achieving the same thing?

Patrick

  • a maintainer of Whonix
  • Administrator
  • *****
  • Posts: 3398
  • (adrelanos)
    • View Profile
    • Patrick Schleizer – Profile Page
Re: Join us testing new AppArmor Profiles! (Whonix Security Hardening)
« Reply #86 on: March 14, 2014, 01:56:55 pm »
sdwdate also needs read access to /var/lib/sdw_error.

Quote
It seems that the normal behavior when running "sudo service sdwdate restart" is that it does not show the timsesync progress window.

You can test on a fresh Whonix-Workstation 8 without any AppArmor profiles, if you run "sudo service sdwdate" restart you always get a progress bar window and the progress bar moves.

Quote
There is no reference to timesync in the sdwdate scripts in /etc/init.d/ or /usr/bin/, and sdwdate on its own does not display anything.

/etc/init.d/sdwdate and /usr/bin/sdwdate indeed do not include any GUI specific code. This is on purpose. The GUI code is implemented in /etc/sdwdate.d/31_timesync_plugin.

sdwdate `eval`uates the contents of $DISPATCH_PRE, which is for example "/usr/lib/whonix/timesync_pre --autostart --mode startup".

Quote
From the test I have done, when you start or reboot the workstation, the gui will show after "sudo service sdwdate restart"  only during the first sleeping period.
This is on purpose. This has to do with --mode startup vs. --mode daemon. When sdwdate starts after reboot or after sdwdate was upgraded by apt-get, $SDW_MODE will be startup. After the first run, next $SDW_MODE will be daemon. This because the user is advised to wait until sdwdate succeeded after the first boot of Whonix for better anonymity. When exactly subsequent runs of sdwdate are executed and how long they take is not so important. It only tries to avoid clock skews and long time likeability. For subsequent runs, sdwdate would only show if sdwdate failed. You can test that on a separate Whonix-Workstation without any AppArmor profiles, when no Whonix-Gateway is available for this Whonix-Workstation, the daemon sdwdate will fail and it's timesync plugin will launch a popup notification.

Another way to test sdwdate error handling is to run "sudo touch /var/lib/sdw_error", after end of current sleep and in the next loop the the daemon an error will be provoked. In the log you will see.

Code: [Select]
6b170e95-07ee-47fe-b1d0-375e99f705fc: dispatching post_error (SDW_MODE: startup): /usr/lib/whonix/timesync_post_error "$error_message" & disown
And also a popup will be shown. (This command /usr/lib/whonix/timesync_post_error "$error_message" can also be used standalone for testing purposes.)

Quote
Aren't both basically achieving the same thing?
No. In essence, for one there is sdwdate, a standalone daemon which has been extended with a timesync plugin. From sdwdate perspective, the sdwdate plugin is used to inform terminal and X users about important events that would otherwise go unnoticed in syslog.

When timesync is started, it watches sdwdate's log and runs "sudo service sdwdate restart", keeps the user informed about sdwdate's progress and status independently from sdwdate. (Manually run timesync would be able to diagnose sdwdate failures and bugs.)
HOT: How to Ask Smart Questions | How to Report Bugs Effectively
Impressum | Datenschutzerklärung | Haftungsausschluss
If Whonix (g+) is useful to you, please consider a reoccurring donation so I (e-mail) (gpg) (g+) can work full time on Whonix.
Need more attention? Get Professional Support!

Patrick

  • a maintainer of Whonix
  • Administrator
  • *****
  • Posts: 3398
  • (adrelanos)
    • View Profile
    • Patrick Schleizer – Profile Page
Re: Join us testing new AppArmor Profiles! (Whonix Security Hardening)
« Reply #87 on: March 14, 2014, 02:27:56 pm »
I've written a sdwdate_simulator.

Code: [Select]
#!/bin/bash

set -x
set -o pipefail

declare -g SDWDATE_POOL_NEUTRAL
declare -A -g SDWDATE_CURL_DISPATCH_PRE
declare -A -g SDWDATE_CURL_DISPATCH_POST

for i in /etc/sdwdate.d/*; do
   if [ -f "$i" ]; then
      ## If the last character is a ~, ignore that file, because it was created
      ## by some editor, which creates backup files.
      if [ "${i: -1}" = "~" ]; then
         continue
      fi
      ## Skipping files such as .dpkg-old and .dpkg-dist.
      if ( echo "$i" | grep -q ".dpkg-" ); then
         true "skip $i"
         continue
      fi
      source "$i"
   fi
done

SDW_MODE="startup"

while true; do

   #SDW_MODE="daemon"

   SDWDATE_CURRENT_POOL="neutral"

   ## Opens progress bar in X, informs
   eval $DISPATCH_PRE

   ## Checks if Tor has finished bootstrapping yet
   #eval $DISPATCH_PREREQUISITE

   sleep 5

   ## Moves progress bar running curl for that pool.
   true "Will run: eval ${SDWDATE_CURL_DISPATCH_PRE[SDWDATE_POOL_NEUTRAL]}"
   eval ${SDWDATE_CURL_DISPATCH_PRE[SDWDATE_POOL_NEUTRAL]}

   sleep 5

   ## In case any tool exits an unexpected non-zero exit code while running sdwdate.
   #eval $DISPATCH_POST_ERROR

   ## Moves progress bar running curl after that pool.
   true "Will run: eval ${SDWDATE_CURL_DISPATCH_POST[SDWDATE_POOL_NEUTRAL]}"
   eval ${SDWDATE_CURL_DISPATCH_POST[SDWDATE_POOL_NEUTRAL]}

   sleep 5

   ## In case sdwdate succeeded.
   eval $DISPATCH_POST_SUCCESS

   ## In case sdwdate did not succeed, for example one pool was unreachable.
   #eval $DISPATCH_POST_FAILURE

   SDW_MODE="daemon"

   sleep 15

done

This is what sdwdate basically does while leaving out the actual time synchronization code. You can use this for testing. Either to just look it at it as a reference how it's working, or to write a profile for /usr/bin/sdwdate_simulator (just to find out what's missing in the actual sdwdate profile), or use this code to temporarily replace the actual /usr/bin/sdwdate to make debugging the AppArmor profile easier.
HOT: How to Ask Smart Questions | How to Report Bugs Effectively
Impressum | Datenschutzerklärung | Haftungsausschluss
If Whonix (g+) is useful to you, please consider a reoccurring donation so I (e-mail) (gpg) (g+) can work full time on Whonix.
Need more attention? Get Professional Support!

Patrick

  • a maintainer of Whonix
  • Administrator
  • *****
  • Posts: 3398
  • (adrelanos)
    • View Profile
    • Patrick Schleizer – Profile Page
Re: Join us testing new AppArmor Profiles! (Whonix Security Hardening)
« Reply #88 on: March 14, 2014, 02:33:08 pm »
I think it would be best if sdwdate was allowed to exec all /usr/lib/whonix/timesync_... scripts unconstrained by AppArmor profiles while also preserving the environment variables. I don't think these scripts have potential to be exploited. I think what they need is unconstrained execute mode (ux) but I don't know enough about AppArmor. This is because the /usr/lib/whonix/timesync_... scripts need lots of permissions for themselves for notification stuff which may not be allowed by the current sdwdate AppArmor profile.
HOT: How to Ask Smart Questions | How to Report Bugs Effectively
Impressum | Datenschutzerklärung | Haftungsausschluss
If Whonix (g+) is useful to you, please consider a reoccurring donation so I (e-mail) (gpg) (g+) can work full time on Whonix.
Need more attention? Get Professional Support!

troubadour

  • Moderator
  • *****
  • Posts: 594
    • View Profile
Re: Join us testing new AppArmor Profiles! (Whonix Security Hardening)
« Reply #89 on: March 17, 2014, 12:24:36 am »
Quote
I think it would be best if sdwdate was allowed to exec all /usr/lib/whonix/timesync_... scripts unconstrained by AppArmor profiles while also preserving the environment variables. I don't think these scripts have potential to be exploited. I think what they need is unconstrained execute mode (ux) but I don't know enough about AppArmor. This is because the /usr/lib/whonix/timesync_... scripts need lots of permissions for themselves for notification stuff which may not be allowed by the current sdwdate AppArmor profile.

I have authorized all /usr/lib/whonix/timesync_... scripts, including the ones not required by apparmor plus msgcollector and msgprogress, to run unconfined.
Code: [Select]
/usr/lib/whonix/timesync_pre rwUx,
/usr/lib/whonix/timesync_post_error rwUx,
/usr/lib/whonix/timesync_prerequisite rwUx,
/usr/lib/whonix/timesync_post_success rwUx,
/usr/lib/whonix/usr/timesync_init_d rwUx,
/usr/lib/whonix/usr/timesync_post_failure rwUx,
/usr/lib/whonix/msgcollector rUx,
/usr/lib/whonix/msgprogress rUx,
To no avail. I had actually started in that direction.

In order to make a fresh start, all the profiles were moved in a tmp directory. Run “sudo service apparmor teardown” for good measure.

Here a digest of my tests.

Reboot the workstation.
   - timesync notification OK

Run “service sdwdate restart” several times.
   - timesync GUI, progress bar
   - timesync notification OK

 Wait after first sleep period. Run "sudo service sdwdate restart"
[@error]
   - no timesync GUI
   - timesync success notification

Run timesync.
[@OK]
   - timesync GUI, progress bar
   - timesync notification OK

Run "sudo service sdwdate restart" several times.[@OK]

Run sdwdate_simulator once (ctrl-c during the 15s sleep period) [@OK]

Run "sudo service sdwdate restart" several times.[@OK]

Let sdwdate_simulator run twice. [@error]

Run "sudo service sdwdate restart" . [@error]

Run timesync. [@OK].   And so on...

 

Legal

Impressum Datenschutz Haftungsausschluss Contact

Links

Homepage Blog Issues Github

Misc

Contribute Donate Investors Free Support Professional Support