[apparmor] Apparmor

[Seth Arnold]

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.

Дякую
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20190829/b97f9c29/attachment.sig>