[refpolicy] Possible regression and bug in userdom_base_user_template

[refpolicy] Possible regression and bug in userdom_base_user_template

[Michal Svoboda]

Hi,

I use a call like userdom_base_user_template(foo) to create foo_u, foo_r
and foo_t. On my debian installation with refpolicy 20080702, this
creates the following:

sesearch --allow -s foo_t -p execute_no_trans
   allow foo_t ld_so_t : file { ioctl read getattr execute execute_no_trans } ; 
   allow foo_t usr_t : file { ioctl read getattr lock execute execute_no_trans } ; 

Fast forward to today's refpolicy (or at least the one in fedora 12),
and you get

   allow foo_usertype application_exec_type : file { ioctl read getattr lock execute execute_no_trans open } ;
   allow foo_usertype bin_t : file { ioctl read getattr lock execute execute_no_trans open } ;
   allow foo_usertype chroot_exec_t : file { ioctl read getattr lock execute execute_no_trans open } ;
   allow foo_t usr_t : file { ioctl read getattr execute execute_no_trans open } ;
   allow foo_usertype ld_so_t : file { ioctl read getattr execute execute_no_trans open } ;
   allow foo_usertype shell_exec_t : file { ioctl read getattr lock execute execute_no_trans open } ;

So here go my questions:
1) What's the story with the usr_t? The only executable files with that
label are possibly in /usr/games, and that one could have its own
usrgames_t or so.
2) Why such an implosion of executable permissions? On the old system,
the new user can't execute almost anything, on the new system such an
identity equals free shell access.

Regards,
Michal Svoboda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20100224/bb69f532/attachment-0001.bin 

[refpolicy] Possible regression and bug in userdom_base_user_template

[Christopher J. PeBenito]

On Wed, 2010-02-24 at 11:54 +0100, Michal Svoboda wrote:
> Hi,
> 
> I use a call like userdom_base_user_template(foo) to create foo_u, foo_r
> and foo_t. On my debian installation with refpolicy 20080702, this
> creates the following:
> 
> sesearch --allow -s foo_t -p execute_no_trans
>    allow foo_t ld_so_t : file { ioctl read getattr execute execute_no_trans } ; 
>    allow foo_t usr_t : file { ioctl read getattr lock execute execute_no_trans } ; 
> 
> Fast forward to today's refpolicy (or at least the one in fedora 12),
> and you get
> 
>    allow foo_usertype application_exec_type : file { ioctl read getattr lock execute execute_no_trans open } ;
>    allow foo_usertype bin_t : file { ioctl read getattr lock execute execute_no_trans open } ;
>    allow foo_usertype chroot_exec_t : file { ioctl read getattr lock execute execute_no_trans open } ;
>    allow foo_t usr_t : file { ioctl read getattr execute execute_no_trans open } ;
>    allow foo_usertype ld_so_t : file { ioctl read getattr execute execute_no_trans open } ;
>    allow foo_usertype shell_exec_t : file { ioctl read getattr lock execute execute_no_trans open } ;
> 
> So here go my questions:
> 1) What's the story with the usr_t? The only executable files with that
> label are possibly in /usr/games, and that one could have its own
> usrgames_t or so.
> 2) Why such an implosion of executable permissions? On the old system,
> the new user can't execute almost anything, on the new system such an
> identity equals free shell access.

The Fedora list is more appropriate for this discussion, as these rules
are specific to the Fedora policy.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150

[refpolicy] Possible regression and bug in userdom_base_user_template

[Alan Rouse]

Chris PeBenito wrote:
> The Fedora list is more appropriate for this discussion, 
> as these rules are specific to the Fedora policy.

The discussion arises because of problems with OpenSuse 11.2, not Fedora.  It's really about cross-distribution compatibility of the reference policy.

[refpolicy] Possible regression and bug in userdom_base_user_template

[Daniel J Walsh]

On 02/24/2010 05:54 AM, Michal Svoboda wrote:
> Hi,
>
> I use a call like userdom_base_user_template(foo) to create foo_u, foo_r
> and foo_t. On my debian installation with refpolicy 20080702, this
> creates the following:
>
> sesearch --allow -s foo_t -p execute_no_trans
>     allow foo_t ld_so_t : file { ioctl read getattr execute execute_no_trans } ;
>     allow foo_t usr_t : file { ioctl read getattr lock execute execute_no_trans } ;
>
> Fast forward to today's refpolicy (or at least the one in fedora 12),
> and you get
>
>     allow foo_usertype application_exec_type : file { ioctl read getattr lock execute execute_no_trans open } ;
>     allow foo_usertype bin_t : file { ioctl read getattr lock execute execute_no_trans open } ;
>     allow foo_usertype chroot_exec_t : file { ioctl read getattr lock execute execute_no_trans open } ;
>     allow foo_t usr_t : file { ioctl read getattr execute execute_no_trans open } ;
>     allow foo_usertype ld_so_t : file { ioctl read getattr execute execute_no_trans open } ;
>     allow foo_usertype shell_exec_t : file { ioctl read getattr lock execute execute_no_trans open } ;
>
> So here go my questions:
> 1) What's the story with the usr_t? The only executable files with that
> label are possibly in /usr/games, and that one could have its own
> usrgames_t or so.
> 2) Why such an implosion of executable permissions? On the old system,
> the new user can't execute almost anything, on the new system such an
> identity equals free shell access.
>
> Regards,
> Michal Svoboda
>    
>
>
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
>    
Allowing an application to execute usr_t, bin_t or any_t does not cause 
a transition.  You stay in your current domain.  So there is not a 
problem here.  You have the exact same access.  The goal of the policy 
in Fedora is to allow a confined user to execute random applications 
that we dont know about.  So if new binaries get installed in 
/usr/share/myapp/myapp.sh  We want the user to be able to execute it.   
But if xguest_t is not allowed to use the network myapp.sh is not going 
to allow the user to use the network.

We do not know where apps are going to be installed and making all users 
correct labeling is considered onerous and will just lead to people 
disabling SELinux or putting it into permissive mode.
Executing usr_t is not that big of a security risk.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20100224/7d1622f3/attachment-0001.html 

[refpolicy] Possible regression and bug in userdom_base_user_template

[Michal Svoboda]

Christopher J. PeBenito wrote:
> The Fedora list is more appropriate for this discussion, as these rules
> are specific to the Fedora policy.

Okay, it seems so, thanks. But the usr_t rule remains in refpolicy too.
Is the reasoning here the same? That is

Daniel J Walsh wrote:
>    Executing usr_t is not that big of a security risk.

... because from the purity point of view it would seem that usr_t
should be a label of read only, non-executable files.

Michal Svoboda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20100301/0ba2e055/attachment.bin 

[refpolicy] Possible regression and bug in userdom_base_user_template

[Daniel J Walsh]

On 03/01/2010 05:22 AM, Michal Svoboda wrote:
>
> Christopher J. PeBenito wrote:
>    
>> The Fedora list is more appropriate for this discussion, as these rules
>> are specific to the Fedora policy.
>>      
> Okay, it seems so, thanks. But the usr_t rule remains in refpolicy too.
> Is the reasoning here the same? That is
>
> Daniel J Walsh wrote:
>    
>>     Executing usr_t is not that big of a security risk.
>>      
> ... because from the purity point of view it would seem that usr_t
> should be a label of read only, non-executable files.
>
> Michal Svoboda
>    
>
>
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
>    
Yes if my goal was to have anyone who uses an SELinux system, to totally 
understand the difference, but my goal is to have the largest possible 
segment of computer users gain some protection for SELinux.  Forcing 
them to label every package in the world correctly or blowing up the 
application for very little increased security is just nuts.

Right now I have SELinux usage in Fedora at > 70%  If I turned off 
unconfined_t and unconfined initrc_t and started preventing execution of 
usr_t, I would bet that number would collapse.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20100301/1f7b49ee/attachment.html 

[refpolicy] Possible regression and bug in userdom_base_user_template

[Christopher J. PeBenito]

On Mon, 2010-03-01 at 11:22 +0100, Michal Svoboda wrote:
> 
> Christopher J. PeBenito wrote:
> > The Fedora list is more appropriate for this discussion, as these rules
> > are specific to the Fedora policy.
> 
> Okay, it seems so, thanks. But the usr_t rule remains in refpolicy too.
> Is the reasoning here the same? That is
> 
> Daniel J Walsh wrote:
> >    Executing usr_t is not that big of a security risk.
> 
> ... because from the purity point of view it would seem that usr_t
> should be a label of read only, non-executable files.

In an ideal world, usr_t files would be treated as you say.  The problem
is that packages put their files all over the place (have you looked to
see what files are executable in /usr/share?).  I agree with Dan, I
don't feel its a big deal.  usr_t files should be high integrity system
files, just like bin_t files are.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150

[refpolicy] Possible regression and bug in userdom_base_user_template

[Michal Svoboda]

Hi,

Christopher J. PeBenito wrote:
> (have you looked to see what files are executable in /usr/share?)

I don't seem to have any. But let's assume there are such.

> I agree with Dan, I don't feel its a big deal.  usr_t files should be
> high integrity system files, just like bin_t files are.

It seems a little odd that usr_t privilege is in refpolicy, but bin_t is
a fedora ext.

However, this all was beside my point. Suppose it's a good thing, the
way the base_user_template macro works right now. I understand that
user_u will want to poke wildlife things in /usr/share, but that doesn't
mean every se-user needs to that. So is there a macro that defines a
really minimal user?

For example, if I want to create a restricted user type for sftp or svn
that does not require executing anything besides one fixed program, what
macro or template should I use?

Regards,
Michal Svoboda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20100301/6062b249/attachment.bin 

[refpolicy] Possible regression and bug in userdom_base_user_template

[Christopher J. PeBenito]

On Mon, 2010-03-01 at 16:01 +0100, Michal Svoboda wrote:
> Christopher J. PeBenito wrote:
> > (have you looked to see what files are executable in /usr/share?)
> 
> I don't seem to have any. But let's assume there are such.
> 
> > I agree with Dan, I don't feel its a big deal.  usr_t files should be
> > high integrity system files, just like bin_t files are.
> 
> It seems a little odd that usr_t privilege is in refpolicy, but bin_t is
> a fedora ext.

I don't know what you are referring to; I don't see such access in
refpolicy.  I can see that the base user template can read usr_t files,
but not execute them.  I even added a test user that only called the
template and opened up the compiled policy with apol; it still did not
have an execute permission on usr_t.

> However, this all was beside my point. Suppose it's a good thing, the
> way the base_user_template macro works right now. I understand that
> user_u will want to poke wildlife things in /usr/share, but that doesn't
> mean every se-user needs to that. So is there a macro that defines a
> really minimal user?
> 
> For example, if I want to create a restricted user type for sftp or svn
> that does not require executing anything besides one fixed program, what
> macro or template should I use?

There is no template that restrictive.  In fact, its impossible to
accomplish that unless you have statically-linked programs, since
dynamic linking requires execute on shared libraries.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150

[refpolicy] Possible regression and bug in userdom_base_user_template

[Michal Svoboda]

Christopher J. PeBenito wrote:
> I don't know what you are referring to; I don't see such access in
> refpolicy.  I can see that the base user template can read usr_t files,
> but not execute them.  I even added a test user that only called the
> template and opened up the compiled policy with apol; it still did not
> have an execute permission on usr_t.

This is weird.

# cat foo.te
policy_module(foo,1.0.0)

userdom_base_user_template(foo)

# sesearch --allow -s foo_t -p execute_no_trans
Found 2 semantic av rules:
   allow foo_t usr_t : file { ioctl read getattr lock execute
   				execute_no_trans open } ;
   allow foo_t ld_so_t : file { read getattr execute execute_no_trans open } ;

# aptitude show selinux-policy-default |grep -i vers
Version: 2:0.2.20091117-1

Either the policy changed since then or this is a debian only patch...

> There is no template that restrictive.  In fact, its impossible to
> accomplish that unless you have statically-linked programs, since
> dynamic linking requires execute on shared libraries.

I know, that's the ld_so_t, but on that one you could semi-count that
it's not used outside its ideal world scope.

Michal Svoboda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20100301/7c751a31/attachment.bin 

[refpolicy] Possible regression and bug in userdom_base_user_template

[Martin Orr]

On Mon  1 Mar 17:03:24 2010, Michal Svoboda wrote:

> Christopher J. PeBenito wrote:
>> I don't know what you are referring to; I don't see such access in
>> refpolicy.  I can see that the base user template can read usr_t files,
>> but not execute them.  I even added a test user that only called the
>> template and opened up the compiled policy with apol; it still did not
>> have an execute permission on usr_t.
>
> This is weird.
>
> # cat foo.te
> policy_module(foo,1.0.0)
>
> userdom_base_user_template(foo)
>
> # sesearch --allow -s foo_t -p execute_no_trans
> Found 2 semantic av rules:
>    allow foo_t usr_t : file { ioctl read getattr lock execute
>    				execute_no_trans open } ;
>    allow foo_t ld_so_t : file { read getattr execute execute_no_trans 
> open } ;
>
> # aptitude show selinux-policy-default |grep -i vers
> Version: 2:0.2.20091117-1
>
> Either the policy changed since then or this is a debian only patch...

Yes, this is a Debian only patch.  According to my history, it was 
added somewhere between 0.0.20080702-1 and 0.0.20080702-4.

-- 
Martin Orr

[refpolicy] Possible regression and bug in userdom_base_user_template

[Michal Svoboda]

Martin Orr wrote:
> Yes, this is a Debian only patch.  According to my history, it was
> added somewhere between 0.0.20080702-1 and 0.0.20080702-4.

Sigh. I guess the reasoning behind this is the same as in fedora? I'm
getting a little dizzy about these distro specific patches. Sad too.

Michal Svoboda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20100301/d0eb6518/attachment.bin 

[refpolicy] Possible regression and bug in userdom_base_user_template

[Christopher J. PeBenito]

On Mon, 2010-03-01 at 21:14 +0100, Michal Svoboda wrote:
> Martin Orr wrote:
> > Yes, this is a Debian only patch.  According to my history, it was
> > added somewhere between 0.0.20080702-1 and 0.0.20080702-4.
> 
> Sigh. I guess the reasoning behind this is the same as in fedora? I'm
> getting a little dizzy about these distro specific patches. Sad too.

Well, unfortunately, thats how things work in Linux distros.  If you
look at Fedora cvs or other distros' packaging RCSs, you'll see patching
happening on many packages.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150

[refpolicy] Possible regression and bug in userdom_base_user_template

[Daniel J Walsh]

On 03/02/2010 09:13 AM, Christopher J. PeBenito wrote:
> On Mon, 2010-03-01 at 21:14 +0100, Michal Svoboda wrote:
>    
>> Martin Orr wrote:
>>      
>>> Yes, this is a Debian only patch.  According to my history, it was
>>> added somewhere between 0.0.20080702-1 and 0.0.20080702-4.
>>>        
>> Sigh. I guess the reasoning behind this is the same as in fedora? I'm
>> getting a little dizzy about these distro specific patches. Sad too.
>>      
> Well, unfortunately, thats how things work in Linux distros.  If you
> look at Fedora cvs or other distros' packaging RCSs, you'll see patching
> happening on many packages.
>
>    
That is also how innovation happens.  When someone has a good idea they 
first try it out within their distribution.  If it turns out it works 
well then hopefully they upstream it.  If upstream accepts the patch 
then all distributions benefit.  Sometimes upstream does not accept the 
patch for one reason or another and distributions copy each others patches.

[refpolicy] Possible regression and bug in userdom_base_user_template

[Michal Svoboda]

Martin Orr wrote:
> Yes, this is a Debian only patch.  According to my history, it was
> added somewhere between 0.0.20080702-1 and 0.0.20080702-4.

Daniel J Walsh wrote:
> That is also how innovation happens. 

I obviously don't want to obstruct the way to innovation, but try to see
the situation through my eyes.

I want to develop my custom modules on top of refpolicy. To do that I
use the publicly available interface reference on tresys website. I take
it as the contract for the macros I use, like userdom_base_user_domain.

On fedora/debian/... the macro behaves differently without any sign of
delta documentation and/or tresys-like interface reference. (Actually
the discussed change is deeper than that, potentially breaking also
other interfaces.) To me such a change is as if you (silently or not)
changed the contract for the fopen() C function and obviously many
developers would be unhappy if that function would behave differently on
different distros.

Why didn't you simply create your own macro (or module) that extends the
original functionality and use that for where you think it should be
used (say user_u) and leave the original interface untouched?

Regards,
Michal Svoboda

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20100303/ab224bd9/attachment.bin