[email protected] wrote:
> Yes people may think differently. But every person understand concept of
> read-only
> directory or ro mount. So to simplify understanding generic writable_access
> operation
> could implement all restrictions to implement usual read-only mount/dir.
If you care about bypassed accesses, read-only directory and read-only mount
cannot be implemented unless rules are written using inode's attributes.
> >> I think I covered all operations that can modify files, excluding all that
> >> read only.
> >
> > This is different from my expected usage.
>
> I don't understand, what is different from expected use? I want to make some
> directory globally read only except for its accessor software. I think this
> is useful
> in general and also useful insecurity sense. For example to protect backups
> from
> accidental/intentional modifications. It is security for backups integrity.
I think your rules which are written using pathnames are incomplete.
I assume BACKUPS refers a name group which is defined like
name_group BACKUPS /home/backup/\(\*\)/\*
. You are trying to restrict unlink operation.
1 acl unlink path=@BACKUPS
This rule is OK as long as you don't care about bypassed accesses via
manipulating pathnames.
However, you have also defined rules which try to restrict mount operation
because you seem to care about bypassed accesses via manipulating pathnames.
1 acl mount source=@BACKUPS
1 acl mount target=@BACKUPS
These rules would block bypassed accesses like
# mount --bind /home/backup/ /tmp/
# unlink /tmp/yourbackup
. But why you don't care about bypassed accesses like
# mount --bind /home/ /tmp/
# unlink /tmp/backup/yourbackup
?
What if filesystem namespace is unshared and pivot_root is used for bringing
/home/backup to somewhere else?
You have defined rules which try to restrict rename operation.
1 acl rename old_path=@BACKUPS
1 acl rename new_path=@BACKUPS
These rules would block bypassed accesses like
# mv /home/backup /home/tmp
# unlink /home/tmp/yourbackup
. But why you don't care about bypassed accesses like
# mv /home /home2
# unlink /home2/backup/yourbackup
?
So, my expected usage for your will is to use inode's attributes.
For example, if you can allocate a dedicated partition for /home/backup
(say /dev/sda2), you can use "path.major" and "path.minor" rather than "path".
1 acl unlink path.major=8 path.minor=2
1 allow ...
2 deny
For another example, if you can allocate a dedicated user id for files and
directories in /home/backup (say 500), you can use "path.uid" rather than
"path".
1 acl unlink path.uid=500
1 allow ...
2 deny
1 acl chown path.uid=500
1 allow ...
2 deny
In this way, you don't need to care about bypassed accesses via manipulating
pathnames.
Especially for namespace manipulation operations (i.e. mount and pivot_root),
I think that these rules would look like
1 acl mount
1 allow ....
2 allow ....
3 allow ....
4 deny
1 acl pivot_root
1 allow ....
2 allow ....
3 allow ....
4 deny
. Also, ioctl rules would look like
1 acl ioctl path.type=file
1 allow cmd=@IOCTL_CMDS_FOR_FILE
2 deny
if you care about (and afford restricting) ioctl operations.
Whereas execute rules would look like examples in the PDF document.
_______________________________________________
tomoyo-users-en mailing list
[email protected]
http://lists.sourceforge.jp/mailman/listinfo/tomoyo-users-en
