On Thu, Aug 29, 2019 at 04:02:52PM +0300, Олександр Нещадим wrote: > I want to limit the users of my computer so that they cannot transfer their > files to other users. I limited the chmod command. > But through the Nautilus program, users can change the properties of files. > > Tell me how to limit users who own files. > > I wanted to do this through the Apparmore profile for Nautilus, but I don’t > know how.
Hello Олександр, I'm not sure what your security goals are but it's quite possible that what you want to do isn't possible with AppArmor today. > I read that there is a chmod rule in Apparmore syntax ( > https://web.archive.org/web/20171230174731/http://wiki.apparmor.net/index.php/AppArmor_Core_Policy_Reference#Chmod_rules > ) > But for some reason it does not work. Help me please. I'm sorry, this wiki page isn't documentation -- it was used to sketch out what new features may look like, how those features could interact, etc. It was a mistake to put these notes on the public internet. The apparmor.d(5) manpage is better at documenting what exists; not all features are available everywhere. On Ubuntu it should be comprehensive, on other distributions less good. We're working on upstreaming features so it should improve over time. For today, you can use this table to help determine what features may exist on your system: https://gitlab.com/apparmor/apparmor/wikis/Kernel_Feature_Matrix Alright, back to your problem. Two users can communicate via files, sockets, shared memory segments, semaphores, process titles, etc. AppArmor can help you block sockets, but if you let your users get to the internet or off the computer at all, they can communicate that way. If a user can bind a socket and another connect, they can communicate without getting to the internet. We currently don't mediate shared memory segments or semaphores. Process titles can be blocked via procfs(5) mount flag hidepid. AppArmor can help with files but in a different fashion than mediating chmod: the 'owner' flag on files. It applies on path. However, rather than preventing a user from making their files too visible, the 'owner' flag is a restriction on a potential reading (or writing) process. Here's a rough, untested, example: #include <tunables/global> profile users { #include <abstractions/base> /bin/** rmix, /usr/bin/** rmix, owner @{HOME}/** rwlk, owner /tmp/** rwlk, } It would take some effort to ensure all your user processes are confined with this profile. (This is also something we intend to make easier in the future.) Processes confined with this profile would not be able to read files owned by other users within their home directories. Executables (and libraries, other files via abstractions/base) can by owned by anyone and still be read. There's no sockets in this, so that route is out. Shared memory segments, semaphores, and process titles would still work for inter-process communication. If this is applied to all user processes, then no user would be able to change their passwords. They couldn't use any setuid executables owned by other users. It wouldn't be a standard Unix-like system by a long shot. But it might be good enough for your use. I hope this helps. Дякую
signature.asc
Description: PGP signature
-- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
