Thanks for the reply!
31.12.2012, 15:18, "Tetsuo Handa" <[email protected]>:
> [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.
Now I see what you mean. Yes, my approach (for backups protection) does not
protect
against intentional deletion, but still protect against accidental
deletion/curruption of backup
data, which is still very good (for me).
>>>> 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/\(\*\)/\*
No, I used strings_group. I don't even see name_group in caitsith doc.
> . 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
>
> ?
You are right. So to protect against intentional deletion/tampering I need to
restrict remount of all upper level directories too. Hm. I don't see general
tools in
caitsith for that.
Or I should mount --make-unbindable /home/backup and then forbid umount of that.
Or I should forbid bind mounts overall, (since they are rarely (if at all) used
on my server).
> What if filesystem namespace is unshared and pivot_root is used for bringing
> /home/backup to somewhere else?
I'm not very understood pivot_root concept, will after pivot_root path checked
as full
realpath or it will stripped to containt only after the pivot_root part?
> 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
>
> ?
ic.. Would be good to restrict that too. I probably should add deny rule
for renaming /home too. One more rule is not that bad.
> 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
I can not.
> 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".
I can not too. (This is snapshot type backup so files uid/gid can not be
changed.)
> In this way, you don't need to care about bypassed accesses via manipulating
> pathnames.
Maybe I still can use pathname apprach if protecting carefully against corner
cases.
You did nice suggestions, thanks!
Btw, maybe can caitsith be extended to support more per inode
restrinctions/checks?
I remember there is path.ino variable. But it seems it can't really protect
some particular inode from access, since it report only for last element in the
pathname (i.e. full pathname) and parent directory.
People, to access protected data, still need to _traverse_ path, so if it's
possible to have operation like 'traverse' and apply rules to it if it's
anywhere in the file path that would be useful. Example suggestion:
1 acl traverse path.ino=1234567 path.major=8 path.minor=2
1 deny
Is this possible to implement?
If yes, this could be extended to:
1 acl traverse path.ino=1234567 path.major=8 path.minor=2
1 allow path="/home/backup"
1 deny
To allow access to this inode directory only if it is in it's canonical
filesystem place, but not otherwise.
Or have shorthand, instead of three rules like "path.ino=1234567 path.major=8
path.minor=2" to have path.stat="8:2:1234567". Later that can be extended to
have pseudo pathname check, for example path.stat="/home/backup" which mean "on
the time of loading rules determine min/maj/ino of path '/home/backup' and
later check with only these numbers".
Then this can be extended to check if operation have some traverse point in
realpath. Like, if I have /home/backup's min/maj/ino somewhere in the checked
path, then such rules apply. Like:
maj_min_ino_group READONLIES "/home/backup/data2" # maj_min_ino_group determine
attributes on time of rules load
maj_min_ino_group READONLIES "/home/backup/data3"
1 acl write anypathelementhave.stat=@READONLIES
1 allow task.exe="/usr/bin/rsync"
2 deny
Sorry for too many suggestions in single mail. ;)
Best regards,
_______________________________________________
tomoyo-users-en mailing list
[email protected]
http://lists.sourceforge.jp/mailman/listinfo/tomoyo-users-en
