On 3/25/21 11:58 PM, Jacek wrote: > Hi > > Whenever a program tries to touch a forbidden resource, the system > (Apparmor?) replies Acces Denied. > > > Some programs may overreact in this case. > > My suggestion for apparmor access policy: > add the hide option, which causes when the application tries to touch the > forbidden resource, it is also denied access, but with the message "No such > file or directory". > > This will help avoid errors when the program tries to check, for example / > sys / module / apparmor, / sys / kernel / security, or ~/.ssh/, > and will exit with a fatal error if access is denied. >
it helps some times, but is very much still an error code and dependent on how the application is handling returned errors. With that said hiding via returning ENOENT instead of EACCES is part of the extended perm work that should be landing upstream over the next cycle or two. Eg. hide w /foo/bar, This of course doesn't stop an application from being able to discover something isn't right, eg. if you give directory read access the dir listing will show the entry that is being hidden, this as you said is more about trying not to break certain applications. The other option you have is the heavy hammer of killing the task instead. Currently that is limited to a profile flag but the extended perm work will make that possible to specify at the rule level. kill w /etc/password, > Originally such a solution is in Grsecurity ACL: > > > Object modes: ... > > h - This object is hidden. > > > https://grsecurity.net/gracldoc.htm > > > Regards > > Jacek > > > > > -- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
