5:45 p.m.
On 01/21/2015 01:13 PM, Bhuvan Gupta wrote:
Hello,
After doing some more investigation */your explanation make perfect
sense/*.
But while going through my own mail i released that the two allow rule
that i mentioned:
[1] /allow sandbox_domain default_t : file { ioctl read write
getattr lock append };/
/[2] / /allow domain usr_t : dir { ioctl read getattr lock search
open };/
/
/
If you notice that the first one has /*sandbox_domain*/ and second one
just /*domain*/
/*sandbox_domain is an attribute of all sandbox_t types
seinfo -asandbox_domain -x
domain is the attribute of all process types. So the second allow rules
says every process
on the system is allowed to search through usr_t directories.
*/
I understand the domain and types are same so sandbox_domain ==
sandbox_t.
But what does domain in [2] signifies ?
Thanks a lot.
On Wed, Jan 21, 2015 at 7:50 PM, Daniel J Walsh <dwalsh(a)redhat.com
<mailto:dwalsh@redhat.com>> wrote:
On 01/21/2015 12:28 AM, Bhuvan Gupta wrote:
> I am working with selinux sandbox
> "http://danwalsh.livejournal.com/28545.html".
>
> Blog clearing mentions that the sandbox "Can not Open or Create
> any files on the system " except the the shared libraries.
>
> But current sandbox allow to read dir stuff which i think should
> not be allowed:
> currently i can successfully ran: /
> "sandbox ls /usr"/
> ls -Z for my /usr is:
> /drwxr-xr-x. root root system_u:object_r:usr_t:s0 usr/
>
Right this is system objects. You are allowed to read/execute
most content under /usr, since sandbox needs to execute programs.
> Now i used sesearch based policy analysis tool to find the allow
> rules and i have listed few which i can understand and think
> should not be there:
> [1] /allow sandbox_domain default_t : file { ioctl read write
> getattr lock append } ; / # sandbox_t is allow to read write to
> file having type as default_t, but it doesnt allow to open it..so
> whats the significance of {read write}
This is for leaking a file descriptor into the container. cat
/foo/bar | sandbox app > /tmp/output
We want to allow a user to open a file descriptor to any object on
the machine and then leak the file descriptor into the sandboxed
app. The sandboxed app is not allowed to Open any files on the
system except content with base labels, like usr_t, etc_t, bin_t,
lib_t. And these labels it is not allowed to write.
> [2] /allow domain usr_t : dir { ioctl read getattr lock search
> open } /
>
> Added my system details and also attached the completed allowed
> list .
>
> I have started with selinux about 1 week back so there might be
> problem with my thinking model.
> /*Does the above stuff make sense from logical point of view and
> should fixed ?*/
> Initially i thought that i will just disallow what i dont
> want...but know i have realised that selinux is denial by default
> model and we can only allow stuff.
>
Correct. If you want to write a more confined SELinux Type, you
can, but you have to start from scratch. And then you allow what
you want. There is an effort to build
a new language called CIL, which would allow you to take an
existing type and create a new type based on that type and remove
access. But we currently do not use this language
> >>yum list installed | grep selinux
> libselinux.x86_64 2.2.2-6.el7
> libselinux-python.x86_64 2.2.2-6.el7
> libselinux-utils.x86_64 2.2.2-6.el7
> selinux-policy.noarch 3.12.1-153.el7_0.13
> selinux-policy-devel.noarch 3.12.1-153.el7_0.13
> selinux-policy-sandbox.noarch 3.12.1-153.el7_0.13
> selinux-policy-targeted.noarch
> 3.12.1-153.el7_0.13
>
> >> yum list installed | grep sandbox
> selinux-policy-sandbox.noarch 3.12.1-153.el7_0.13
>
> Thanks
> Bhuvan
>
> On Tue, Jan 20, 2015 at 2:36 AM, Daniel J Walsh
> <dwalsh(a)redhat.com <mailto:dwalsh@redhat.com>> wrote:
>
> What do you want to Disallow?
>
>
> On 01/18/2015 06:34 AM, Bhuvan Gupta wrote:
>> Hello,
>>
>> "Audit2allow" can add rule to allow some operation.
>> But let say we want to disallow some operation which is
>> allowed by some policy module. let say open operation on
>> some files.
>>
>> Is there a easy way to achieve that ?
>>
>> Or i do have to:
>> [1] get the policy source.
>> [2] edit it accordingly
>> [3] build and reinstall the policy.
>>
>>
>> Thanks
>> Bhuvan
>>
>>
>>
>>
>> --
>> selinux mailing list
>> selinux(a)lists.fedoraproject.org
<mailto:selinux@lists.fedoraproject.org>
>> https://admin.fedoraproject.org/mailman/listinfo/selinux
>
>
--
selinux mailing list
selinux(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux