headers
Milton Yates | 7 Feb 22:43

[tomoyo-users-en 458] Re: Tomoyo 1.8 connections on UDP 0

Le 12/01/2012 03:27, Tetsuo Handa a écrit :
> Milton Yates wrote:
>> I have found that Tomoyo generates logs like this:
>> "network inet dgram send X.X.X.X 0"
>> connection attempts on UDP port 0, for every outbound inet TCP
>> connection the program makes.
> 
> TOMOYO checks "send" permission rather than "connect" permission when connect()
> is called on a connectionless socket, for connect() on a connectionless socket
> is used for associating default destination address that will be used when
> destination address is omitted upon subsequent sendmsg() request. Thus,
> learning "network inet dgram send" entries upon connect() is a known behaviour.

I am not sure this is what Tomoyo logs here, otherwise I did not clearly
understood your point.

>> Is sending to UDP 0 still how the OS finds a free port?
> 
> I don't think so. bind() to port 0 is a way to let the OS find a free port,
> but connect()/send() to port 0 do not make sense (with an exception that
> connect(AF_UNSPEC) described in "man 2 connect").
> 
>> Would you recommend allowing this activity?
> I don't know. You can try tracing your application like
>   strace -e trace=socket,bind,connect,send,sendmsg /path/to/your/app
> to find what is happening.

I will do that yes, it is just thunderbird or firefox though. For every
new TCP connection it does that.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bhargava Shastry | 12 Feb 16:03
Picon

[tomoyo-users-en 459] Delete policy line API

Hello,

I haven't come across an API for policy line deletion for TOMOYO 1.8. Is there any way to delete portions of domain policy other than doing it manually using ccs-editpolicy? I am thinking of using sed on the domain_policy.conf with the specific string to be deleted.

Thanks,
Bhargava Shastry

_______________________________________________
tomoyo-users-en mailing list
tomoyo-users-en@...
http://lists.sourceforge.jp/mailman/listinfo/tomoyo-users-en
Permalink | Reply | 3 comments |
headers
Toshiharu Harada | 12 Feb 16:32
Picon

[tomoyo-users-en 460] Re: Delete policy line API

Hi,

2012/2/13 Bhargava Shastry <bshas3@...>:
> Hello,
>
> I haven't come across an API for policy line deletion for TOMOYO 1.8. Is
> there any way to delete portions of domain policy other than doing it
> manually using ccs-editpolicy? I am thinking of using sed on the
> domain_policy.conf with the specific string to be deleted.

Yes, there is.

If you give lines like "delete file read ..." to ccs-loadpolicy -d,
"file read ..." access permissions will be revoked.

ccs-diffpolicy compares policy definitions and the results will be
produced as policy editing sequences like the above.

For more information, please take a look at the following.

http://tomoyo.sourceforge.jp/1.8/chapter-6.html

Best regards,
Toshiharu Harada
haradats@...
Permalink | Reply | 2 comments |
headers
Bhargava Shastry | 14 Feb 09:55
Picon

[tomoyo-users-en 461] Re: Delete policy line API

Yes, there is.

If you give lines like "delete file read ..." to ccs-loadpolicy -d,
"file read ..." access permissions will be revoked.

Thanks. But is there a more efficient way of deleting all access control rules associated with a file with a single delete command? Lets say /data/app1/file1.txt has a file read policy line and a file write policy line and that when file1.txt is deleted, we would like to purge all policy lines associated with the file. Does TOMOYO's internal data structures contain a mapping of file to access control rights which can later be purged on delete?
 

Regards,
Bhargava Shastry
_______________________________________________
tomoyo-users-en mailing list
tomoyo-users-en@...
http://lists.sourceforge.jp/mailman/listinfo/tomoyo-users-en
Permalink | Reply | 1 comment |
headers
Toshiharu Harada | 15 Feb 04:27
Picon

[tomoyo-users-en 462] Re: Delete policy line API

2012/2/14 Bhargava Shastry <bshas3@...>:
>> Yes, there is.
>>
>> If you give lines like "delete file read ..." to ccs-loadpolicy -d,
>> "file read ..." access permissions will be revoked.
>
>
> Thanks. But is there a more efficient way of deleting all access control
> rules associated with a file with a single delete command? Lets say
> /data/app1/file1.txt has a file read policy line and a file write policy
> line and that when file1.txt is deleted, we would like to purge all policy
> lines associated with the file. Does TOMOYO's internal data structures
> contain a mapping of file to access control rights which can later be purged
> on delete?

TOMOYO makes decisions based on the subject (process).
You can delete a domain by writing "delete name-of-the-domain" to
/proc/ccs/domain_policy,
create a new domain by writing "name-of-the-new-domain-you-want",
and delete individual access permissions by writing "select
name-of-the-domain" following
"delete file read...". But TOMOYO has no interface nor data structures
to do what you want.
You can, of course, write a program that find finds file1.txt from the
current policy and compose
the requests as combination, not efficient though.

Best regards,
Toshiharu Harada
haradats@...
Permalink | Reply | 0 comments |
headers
Bhargava Shastry | 17 Feb 16:07
Picon

[tomoyo-users-en 463] Tomoyo 1.8 on Android 2.6.35 kernel

Hello,

Is there a patch available for making an Android 2.6.35 kernel with TOMOYO 1.8 support? I gather that 2.6.35 patch exists for the mainline kernel but the same patch does not work cleanly with the Android specific kernel. Also, although 2.6.35 ships with a TOMOYO LSM, I'd prefer 1.8 because of a superior feature set.

Any suggestions?

Regards,
Bhargava Shastry

_______________________________________________
tomoyo-users-en mailing list
tomoyo-users-en@...
http://lists.sourceforge.jp/mailman/listinfo/tomoyo-users-en
Permalink | Reply | 1 comment |
headers
Tetsuo Handa | 17 Feb 16:37
Picon

[tomoyo-users-en 464] Re: Tomoyo 1.8 on Android 2.6.35 kernel

Bhargava Shastry wrote:
> Is there a patch available for making an Android 2.6.35 kernel with TOMOYO
> 1.8 support?

No. I want to update it when kernel for emulator is updated.

> I gather that 2.6.35 patch exists for the mainline kernel but
> the same patch does not work cleanly with the Android specific kernel.
> Also, although 2.6.35 ships with a TOMOYO LSM, I'd prefer 1.8 because of a
> superior feature set.

You can send me (i.e. off-list) a tarball containing files that will be
modified by TOMOYO patches. I'll make patch for that tarball and reply.
Permalink | Reply | 0 comments |

Gmane