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
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
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
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.
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
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
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
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
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
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
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
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
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
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.
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