Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    • Switch to GitLab Next
  • Sign in / Register
  • apparmor apparmor
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 121
    • Issues 121
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 26
    • Merge requests 26
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • AppArmorAppArmor
  • apparmorapparmor
  • Issues
  • #13
Closed
Open
Issue created Aug 29, 2018 by Gold Star@GoldStar611

AppArmor won't confine open-vm-tools

If you create a profile for /usr/bin/vmtoolsd (ubuntu package open-vm-tools) you will consistently notice that aa-status returns the following after boot/reboot

1 processes are unconfined but have a profile defined.
/usr/bin/vmtoolsd (517)

A quick investigation yields that /etc/systemd/system/multi-user.target.wants/open-vm-tools.service is set to start After=local-fs.target

Changing this to After=network-online.target let's AppArmor confine the process but it feels like AppArmor should be starting earlier in the boot sequence so it can catch root services that start up in this manner.

Assignee
Assign to
Time tracking