Discussion:
[tomoyo-users-en 655] caitsith-queryd suggestion
0***@cox.net
2016-10-22 17:21:23 UTC
Permalink
Because Caitsith has the functionality to create deny rules, I was
wondering if you would be open to adding functionality to
caitsith-queryd to ignore certain deny rules. I would like to propose a
"query 0" rule which when triggered with caitsith-queryd running, would
silently bypass prompting.

For example, using the following ruleset I am trying to block
inet_stream_connect connections for all applications, except those I've
whitelisted. I want to be prompted by queryd for violations of this rule
like normal. However, I also want to block blacklisted applications and
not be prompted by caitsith-queryd.

0 acl inet_stream_connect
audit 1
query 0
10 deny task.exe="/usr/bin/rsync"

10 acl inet_stream_connect
audit 1
10 allow task.exe="/usr/bin/curl"
100 deny

If this functionality already exists through more clever rule writing,
please excuse my ignorance. If not, any consideration you may give to my
idea would be appreciated.
Tetsuo Handa
2016-10-23 00:12:49 UTC
Permalink
Hello.
Post by 0***@cox.net
Because Caitsith has the functionality to create deny rules, I was
wondering if you would be open to adding functionality to
caitsith-queryd to ignore certain deny rules. I would like to propose a
"query 0" rule which when triggered with caitsith-queryd running, would
silently bypass prompting.
I wonder for what purpose you are trying to keep caitsith-queryd running.
I think that we use caitsith-queryd only when we do something unusual
(e.g. running software updater) for handling unexpected requests.
Post by 0***@cox.net
For example, using the following ruleset I am trying to block
inet_stream_connect connections for all applications, except those I've
whitelisted. I want to be prompted by queryd for violations of this rule
like normal. However, I also want to block blacklisted applications and
not be prompted by caitsith-queryd.
0 acl inet_stream_connect
audit 1
query 0
10 deny task.exe="/usr/bin/rsync"
10 acl inet_stream_connect
audit 1
10 allow task.exe="/usr/bin/curl"
100 deny
Apart from "query 0", I don't understand what you want to do with these rules.
The latter rule allows only /usr/bin/curl to use connect(AF_INET or AF_INET6)
on SOCK_STREAM sockets.

If you don't want /usr/bin/rsync to generate a query, you want to implement
something like below?

10 acl inet_stream_connect
audit 1
10 allow task.exe="/usr/bin/curl"
20 deny task.exe="/usr/bin/rsync" ignore_query
100 deny
Post by 0***@cox.net
If this functionality already exists through more clever rule writing,
please excuse my ignorance. If not, any consideration you may give to my
idea would be appreciated.
But even if there is a scenario where keeping caitsith-queryd always running
makes sense, I don't think we need to implement it in the kernel side as
policy syntax. Adding a configuration file for caitsith-queryd (e.g.
/etc/caitsith/tools/queryd.conf ) and enumerating filtering rules as with
/etc/caitsith/tools/auditd.conf will be cleaner.
0***@cox.net
2016-10-23 02:13:38 UTC
Permalink
Post by Tetsuo Handa
Hello.
Post by 0***@cox.net
Because Caitsith has the functionality to create deny rules, I was
wondering if you would be open to adding functionality to
caitsith-queryd to ignore certain deny rules. I would like to propose a
"query 0" rule which when triggered with caitsith-queryd running, would
silently bypass prompting.
I wonder for what purpose you are trying to keep caitsith-queryd running.
I think that we use caitsith-queryd only when we do something unusual
(e.g. running software updater) for handling unexpected requests.
I keep ccs-queryd running in a terminal window on my desktop all
the time for monitoring purposes. I find it convenient for when there is
a gap in my rules or maybe an application's behavior has changed after
an update. I keep another one open for monitoring syslog. I'm looking to
use the same model if/when I migrate from CCS to Caitsith.
Post by Tetsuo Handa
Post by 0***@cox.net
For example, using the following ruleset I am trying to block
inet_stream_connect connections for all applications, except those I've
whitelisted. I want to be prompted by queryd for violations of this rule
like normal. However, I also want to block blacklisted applications and
not be prompted by caitsith-queryd.
0 acl inet_stream_connect
audit 1
query 0
10 deny task.exe="/usr/bin/rsync"
10 acl inet_stream_connect
audit 1
10 allow task.exe="/usr/bin/curl"
100 deny
Apart from "query 0", I don't understand what you want to do with these rules.
The latter rule allows only /usr/bin/curl to use connect(AF_INET or AF_INET6)
on SOCK_STREAM sockets.
I only used a rule with a single operation for an example. My
full ruleset denies all network operations for all applications, except
those I whitelist which are many more than just curl. Like an
application firewall of sorts. I also make use of more in depth rules
such as file access for applications such as web browsers and WINE programs.
Post by Tetsuo Handa
If you don't want /usr/bin/rsync to generate a query, you want to implement
something like below?
10 acl inet_stream_connect
audit 1
10 allow task.exe="/usr/bin/curl"
20 deny task.exe="/usr/bin/rsync" ignore_query
100 deny
This would work perfectly! It is a much better implementation
than the separate rule method I proposed.
Post by Tetsuo Handa
Post by 0***@cox.net
If this functionality already exists through more clever rule writing,
please excuse my ignorance. If not, any consideration you may give to my
idea would be appreciated.
But even if there is a scenario where keeping caitsith-queryd always running
makes sense, I don't think we need to implement it in the kernel side as
policy syntax. Adding a configuration file for caitsith-queryd (e.g.
/etc/caitsith/tools/queryd.conf ) and enumerating filtering rules as with
/etc/caitsith/tools/auditd.conf will be cleaner.
I don't know if my desktop usage of keeping caitsith-queryd
always running for monitoring makes any sense for the normal or intended
usage model of Caitsith. Perhaps it may prove to be too much of a corner
case to be worth the time to implement. I really don't know because I
don't know how most people use TOMOYO. I appreciate that you've taken
time to read and respond to my suggestion. Thank you!

Loading...