Sorry for late response. I'm trying to allocate per-task variables from LSM on
kernels >= 2.6.29 (security_task_alloc()/security_task_free() are gone).
Radoslaw Szkodzinski wrote:
> > Therefore, if ask_permission/no_ask_permission are implemented in kernel,
> > I think ask_permission/no_ask_permission should be specified like
> >
> > $profile-PREFERENCE::enforcing={ verbose=no penalty=0 query=yes }
> >
> > in /proc/ccs/profile .
>
> If it is possible to set the profile per domain, then it is fine.
>
Yes, you can.
> >> The other thing missing is a policy definition like an ability to enable
> >> or disable the prompt in the policy file, e.g.
> >>
> >> ask_permission
> >> no_ask_permission
> >>
> > Do you want me to implement ask_permission/no_ask_permission in the kernel?
>
> Not really necessary, unless there's no other way...
> But unfortunately the other way would need sending either this flag
> or the profile name via /proc/ccs/query.
>
Profile number is an integer between 0 and 255. You can use profile number for
ask_permission/no_ask_permission purpose by defining multiple profiles for
enforcing mode. You can define
0-CONFIG={ mode=disabled }
1-CONFIG={ mode=learning }
2-CONFIG={ mode=permissive }
3-CONFIG={ mode=enforcing }
4-CONFIG={ mode=enforcing }
and assign profile 4 to domains you want to enforce and ask permissions
and profile 3 to domains you want to enforce but not ask permissions.
Each domain in /proc/ccs/domain_policy has a line that specifies profile number.
<kernel>
use_profile 3 (or 0 or 1 or 2)
<kernel> /usr/lib/firefox/firefox-bin
use_profile 4
allow_read cookies
allow_write cookies
...
allow_network ...
allow_transit /uid:1234 /usr/lib/firefox/firefox-bin if task.uid=1234
allow_transit /uid:777 /usr/lib/firefox/firefox-bin if task.uid=2345
allow_execute /usr/lib/firefox/plugin-container
<kernel> /usr/lib/firefox/firefox-bin /usr/lib/firefox/plugin-container
use_profile 4
allow_stat /store/downloads
allow_write /store/downloads
allow_execute flash
allow_execute java
...
<kernel> /uid:1234 /usr/lib/firefox/firefox-bin
use_profile 4
allow_write /home/1234/downloads
allow_read /home/1234/downloads
allow_chmod 0770 /home/1234/downloads
# to allow overwriting
allow_rename /home/1234/downloads/* /home/1234/downloads/*
Profile number is included in query message.
/usr/sbin/ccs-queryd can check profile number and reject
immediately if profile number is 3.
#2010-01-10 12:29:35# profile=3 mode=enforcing (global-pid=4561)
> What is necessary is a flag to discern whether ccs-queryd should or
> shouldn't ask, just in the protocol.
I think you can use profile number for that purpose.
> I think ccs-queryd doesn't have the whole ruleset, am I right?
ccs-queryd does not have ruleset, but ccs-queryd can fetch it by reading
/proc/ccs/domain_policy . A shortcut "select global-pid=$GPID\n" allows
ccs-queryd to fetch ruleset for only specific domain.
> The trick is that allow_stat is for files, not allow_stat /some/directory, but
> allow_stat /some/directory/*. This means you can read access flags,
> xattrs, file size and so on.
>
> Could be useful specifically for that firefox case of file save dialog,
> so you can browse directories without a flood of messages,
> then only the write would show you the dialog(s) asking for permission.
>
I don't think read/execute permissions for directory make sense, for they
depends on current directory. Many of MAC implementations check read/execute
permissions on directory, but they can't stop accessing /var/log/messages if
a process's current directory is /var/log/ and that process accesses
/var/log/messages by requesting ./messages rather than /var/log/messages .
/ r-x
/var/ ---
/var/log/ r-x
I don't hear that such implementations traverse up to / directory so that the
administrator can stop that process from accessing /var/log/messages if
one of upper directories does not allow reaching to /var/log/ directory.
In TOMOYO, read/execute permissions for directory is not checked.
If DAC allows stat() syscall on some file or directory, TOMOYO will allow
stat() syscall on that file or directory.
You don't need to specify "allow_stat" keyword for reading access flags,
xattrs, file size and so on because TOMOYO cannot prevent stat() syscall.
> > This is for performance reason and for avoiding flood of warning messages by
> > implicit directory searching such as shell's completion.
>
> Hmm... that is a misconfiguration on part of TOMOYO's user, they
> should fix $PATH
> or... write rules to allow_stat. :)
>
As I explained above, there is no way to deny stat() syscall.
> >> Yes, but I'm not targetting users of emulators, but users in general, say,
> >> a typical Ubuntu user of Firefox, so that I could write:
> >>
> >> (in enforcing mode)
> >> <kernel>
> >> no_ask_permission # possibly default
> >>
> >> <kernel> /usr/lib/firefox/firefox-bin
> >> allow_read cookies
> >> allow_write cookies
> >> ...
> >> allow_network ...
> >> allow_transit /uid:1234 /usr/lib/firefox/firefox-bin if task.uid=1234
> >> allow_transit /uid:777 /usr/lib/firefox/firefox-bin if task.uid=2345
>
> One short tangential question: will it execute these after checking
> current domain for permissions or before?
>
I couldn't understand what the question is.
"allow_transit" is checked when a domainname is written to /proc/ccs/.transit
interface.
> >> allow_execute /usr/lib/firefox/plugin-container
> >> ask_permission
> >
> > <snip>
> >
> > ask_permission makes sense for only enforcing mode. If not enforcing mode,
> > requests are granted without sending to /proc/ccs/query interface.
>
> But it could also be used in permissive mode for deny_*.
> This would mean "everything is permitted, but ask about the things I deny
> here".
>
There will be no difference among
<kernel> /foo1
use_profile 2
ask_permission
and
<kernel> /foo2
use_profile 3
ask_permission
and
<kernel> /foo3
use_profile 1
allow_read /etc/fstab
ask_permission
and
<kernel> /foo4
use_profile 3
if you don't specify targets to ask, for all requests which
did not match allow_* are sent to /proc/ccs/query interface and
are rejected unless $answer == 1 or $answer == 3 (regardless of
profile number assigned to domains).
If targets are specified like
<kernel> /foo5
use_profile 2
allow_execute /bin/ls
allow_read /etc/fstab
ask_execute /bin/bash
where execute request for /bin/bash is sent to /proc/ccs/query
interface, it might make sense. That would be blacklisting approach.
Do you want TOMOYO to support blacklisting approach?
Regards.
_______________________________________________
tomoyo-users-en mailing list
[email protected]
http://lists.sourceforge.jp/mailman/listinfo/tomoyo-users-en
