confining the unconfined_t domain

confining the unconfined_t domain

[Clarkson, Mike R (US SSA)]

I'd like to prevent the unconfined_t domain from executing certain files
associated with domains that I've added. What is the best way to do
this?

I was trying to track down how the unconfined_t domain is given the
executable permissions to all executable files. I assume it is through
the  exec_type attribute somehow. I found the
corecmd_exec_all_executables and corecmd_mmap_all_executables interfaces
in corecommands.if, which both give execute privilege to exec_type, but
I don't see these being called from the unconfined module. Can someone
point out how this privilege is provided to the unconfined_t domain?

Thanks



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: confining the unconfined_t domain

[Stephen Smalley]

On Thu, 2007-08-16 at 10:15 -0700, Clarkson, Mike R (US SSA) wrote:
> I'd like to prevent the unconfined_t domain from executing certain files
> associated with domains that I've added. What is the best way to do
> this?
> 
> I was trying to track down how the unconfined_t domain is given the
> executable permissions to all executable files. I assume it is through
> the  exec_type attribute somehow. I found the
> corecmd_exec_all_executables and corecmd_mmap_all_executables interfaces
> in corecommands.if, which both give execute privilege to exec_type, but
> I don't see these being called from the unconfined module. Can someone
> point out how this privilege is provided to the unconfined_t domain?

Um, unconfined_t is "unconfined".  By definition.

And removing the ability to execute another program doesn't change what
unconfined_t can do (i.e. its actual permissions); it can always create
its own copy of the same code and execute it in unconfined_t.

Use a different domain if you want it to be confined.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: confining the unconfined_t domain

[Clarkson, Mike R (US SSA)]

> -----Original Message-----
> From: Stephen Smalley [mailto:sds@tycho.nsa.gov]
> Sent: Thursday, August 16, 2007 11:07 AM
> To: Clarkson, Mike R (US SSA)
> Cc: selinux@tycho.nsa.gov
> Subject: Re: confining the unconfined_t domain
> 
> On Thu, 2007-08-16 at 10:15 -0700, Clarkson, Mike R (US SSA) wrote:
> > I'd like to prevent the unconfined_t domain from executing certain
files
> > associated with domains that I've added. What is the best way to do
> > this?
> >
> > I was trying to track down how the unconfined_t domain is given the
> > executable permissions to all executable files. I assume it is
through
> > the  exec_type attribute somehow. I found the
> > corecmd_exec_all_executables and corecmd_mmap_all_executables
interfaces
> > in corecommands.if, which both give execute privilege to exec_type,
but
> > I don't see these being called from the unconfined module. Can
someone
> > point out how this privilege is provided to the unconfined_t domain?
> 
> Um, unconfined_t is "unconfined".  By definition.
> 
> And removing the ability to execute another program doesn't change
what
> unconfined_t can do (i.e. its actual permissions); it can always
create
> its own copy of the same code and execute it in unconfined_t.
> 
> Use a different domain if you want it to be confined.

I recognize that it would be better to use the strict policy so that we
didn't have an unconfined_t domain, and we plan to switch in the future
before going to operations, but for now we're using the targeted policy
while in a prototype phase with an upcoming demo.

I'd like to be able to demonstrate some of the power of SELinux by
showing that only domains that have been granted permissions have access
to certain files. It kind of defeats the purpose when absolutely anybody
who logs in to the system can execute these files because they log into
the unconfined_t domain. 

I also recognize that removing execute doesn't prevent copying the file
and executing the copy. But if I can eliminate execute permissions of
unconfined_t, I can presumably eliminate all access if I so choose.
Also, in this particular case, the file in question is owned by root
with the setuid bit set, so limiting execute permissions is more
important. When a non-root user copies a file with the setuid bit set,
the copy of the file does not retain the setuid bit.

Unconfined uses the file_type attribute rather than the exec_type
attribute to get execute privilege to all executables (why?). I know
this because I added a neverallow rule (neverallow unconfined_t
my_exec_t:file execute), and then eliminated the call to
domain_entry_file, and I still got a compile error resulting from the
neverallow rule. However, if I remove the call to files_type, then it
compiles fine. This eliminates all access to the file from the
unconfined_t domain. Will there be any bad side effects to eliminating
the file_type attribute to my_exec_t? Is there really no better way to
accomplish this?

Thanks
 
> 
> --
> Stephen Smalley
> National Security Agency




--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: confining the unconfined_t domain

[Stephen Smalley]

On Thu, 2007-08-16 at 13:37 -0700, Clarkson, Mike R (US SSA) wrote:
> 
> > -----Original Message-----
> > From: Stephen Smalley [mailto:sds@tycho.nsa.gov]
> > Sent: Thursday, August 16, 2007 11:07 AM
> > To: Clarkson, Mike R (US SSA)
> > Cc: selinux@tycho.nsa.gov
> > Subject: Re: confining the unconfined_t domain
> > 
> > On Thu, 2007-08-16 at 10:15 -0700, Clarkson, Mike R (US SSA) wrote:
> > > I'd like to prevent the unconfined_t domain from executing certain
> files
> > > associated with domains that I've added. What is the best way to do
> > > this?
> > >
> > > I was trying to track down how the unconfined_t domain is given the
> > > executable permissions to all executable files. I assume it is
> through
> > > the  exec_type attribute somehow. I found the
> > > corecmd_exec_all_executables and corecmd_mmap_all_executables
> interfaces
> > > in corecommands.if, which both give execute privilege to exec_type,
> but
> > > I don't see these being called from the unconfined module. Can
> someone
> > > point out how this privilege is provided to the unconfined_t domain?
> > 
> > Um, unconfined_t is "unconfined".  By definition.
> > 
> > And removing the ability to execute another program doesn't change
> what
> > unconfined_t can do (i.e. its actual permissions); it can always
> create
> > its own copy of the same code and execute it in unconfined_t.
> > 
> > Use a different domain if you want it to be confined.
> 
> I recognize that it would be better to use the strict policy so that we
> didn't have an unconfined_t domain, and we plan to switch in the future
> before going to operations, but for now we're using the targeted policy
> while in a prototype phase with an upcoming demo.

It doesn't matter what policy you use (targeted or strict); you just
can't reasonably restrict unconfined_t without doing major surgery on
it, and then you have the further problem of once having done major
surgery on it, you no longer have a domain from which you can do admin
tasks.  Better to introduce a separate domain and use it instead.

> I'd like to be able to demonstrate some of the power of SELinux by
> showing that only domains that have been granted permissions have access
> to certain files. It kind of defeats the purpose when absolutely anybody
> who logs in to the system can execute these files because they log into
> the unconfined_t domain.

It is more than being able to execute the file type, but also that it
can e.g.:
- relabel to and from that file type,
- enter the domain associated with the file,
- read/write that type,
- ptrace the domain,
...

> I also recognize that removing execute doesn't prevent copying the file
> and executing the copy. But if I can eliminate execute permissions of
> unconfined_t, I can presumably eliminate all access if I so choose.

Yep, but then it is no longer unconfined_t, and how will you
subsequently update those files?

> Also, in this particular case, the file in question is owned by root
> with the setuid bit set, so limiting execute permissions is more
> important. When a non-root user copies a file with the setuid bit set,
> the copy of the file does not retain the setuid bit.

But now you are relying on DAC for your actual protection.

> Unconfined uses the file_type attribute rather than the exec_type
> attribute to get execute privilege to all executables (why?).

files.if defines the interface for gaining unconfined access to all
files, and files.te implements that by allowing all permissions between
such domains and all file types.  All permissions, including execute.
But write and relabelto are no less important.

>  I know
> this because I added a neverallow rule (neverallow unconfined_t
> my_exec_t:file execute), and then eliminated the call to
> domain_entry_file, and I still got a compile error resulting from the
> neverallow rule. However, if I remove the call to files_type, then it
> compiles fine. This eliminates all access to the file from the
> unconfined_t domain. Will there be any bad side effects to eliminating
> the file_type attribute to my_exec_t? Is there really no better way to
> accomplish this?

Without file_type, you won't be allowed to create or relabel files with
that type (associate check).

Better way is to create a separate domain that is restricted, then
assign your users to it instead of unconfined_t, only letting root use
unconfined_t.  That's the model for the merged targeted+strict policy, I
think, that is being created in rawhide / Fedora 8.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: confining the unconfined_t domain

[Clarkson, Mike R (US SSA)]

> -----Original Message-----
> From: Stephen Smalley [mailto:sds@tycho.nsa.gov]
> Sent: Thursday, August 16, 2007 2:15 PM
> To: Clarkson, Mike R (US SSA)
> Cc: selinux@tycho.nsa.gov; Daniel J Walsh
> Subject: RE: confining the unconfined_t domain
> 
> On Thu, 2007-08-16 at 13:37 -0700, Clarkson, Mike R (US SSA) wrote:
> >
> > > -----Original Message-----
> > > From: Stephen Smalley [mailto:sds@tycho.nsa.gov]
> > > Sent: Thursday, August 16, 2007 11:07 AM
> > > To: Clarkson, Mike R (US SSA)
> > > Cc: selinux@tycho.nsa.gov
> > > Subject: Re: confining the unconfined_t domain
> > >
> > > On Thu, 2007-08-16 at 10:15 -0700, Clarkson, Mike R (US SSA)
wrote:
> > > > I'd like to prevent the unconfined_t domain from executing
certain
> > files
> > > > associated with domains that I've added. What is the best way to
do
> > > > this?
> > > >
> > > > I was trying to track down how the unconfined_t domain is given
the
> > > > executable permissions to all executable files. I assume it is
> > through
> > > > the  exec_type attribute somehow. I found the
> > > > corecmd_exec_all_executables and corecmd_mmap_all_executables
> > interfaces
> > > > in corecommands.if, which both give execute privilege to
exec_type,
> > but
> > > > I don't see these being called from the unconfined module. Can
> > someone
> > > > point out how this privilege is provided to the unconfined_t
domain?
> > >
> > > Um, unconfined_t is "unconfined".  By definition.
> > >
> > > And removing the ability to execute another program doesn't change
> > what
> > > unconfined_t can do (i.e. its actual permissions); it can always
> > create
> > > its own copy of the same code and execute it in unconfined_t.
> > >
> > > Use a different domain if you want it to be confined.
> >
> > I recognize that it would be better to use the strict policy so that
we
> > didn't have an unconfined_t domain, and we plan to switch in the
future
> > before going to operations, but for now we're using the targeted
policy
> > while in a prototype phase with an upcoming demo.
> 
> It doesn't matter what policy you use (targeted or strict); you just
> can't reasonably restrict unconfined_t without doing major surgery on
> it, and then you have the further problem of once having done major
> surgery on it, you no longer have a domain from which you can do admin
> tasks.  Better to introduce a separate domain and use it instead.

I think there may be a fairly simple way to restrict the unconfined_t
domain from having access to specified files. I added an attribute to
files.te called always_confined_type, as well as an interface to
files.if to assign this attribute to a given file type. Then I modified
files.te as follows to use the always_confined_type attribute:

########################################
#
# Unconfined access to this module
#

# Create/access any file in a labeled filesystem;
allow files_unconfined_type {file_type -always_confined_type}:{ file
chr_file } ~execmod;
allow files_unconfined_type {file_type -always_confined_type}:{ dir
lnk_file sock_file fifo_file blk_file } *;

# Mount/unmount any filesystem with the context= option. 
allow files_unconfined_type {file_type -always_confined_type}:filesystem
*;

ifdef(`targeted_policy',`
	tunable_policy(`allow_execmod',`
		allow files_unconfined_type {file_type
-always_confined_type}:file execmod;
	')
')

This denies all access to the file type given the always_confined_type
attribute, so if you want to be able to do anything with that file type,
you'll have to do from some domain which has been explicitly granted
appropriate permissions.

Do you see any problems with this approach?

> 
> > I'd like to be able to demonstrate some of the power of SELinux by
> > showing that only domains that have been granted permissions have
access
> > to certain files. It kind of defeats the purpose when absolutely
anybody
> > who logs in to the system can execute these files because they log
into
> > the unconfined_t domain.
> 
> It is more than being able to execute the file type, but also that it
> can e.g.:
> - relabel to and from that file type,
> - enter the domain associated with the file,
> - read/write that type,
> - ptrace the domain,
> ...
> 
> > I also recognize that removing execute doesn't prevent copying the
file
> > and executing the copy. But if I can eliminate execute permissions
of
> > unconfined_t, I can presumably eliminate all access if I so choose.
> 
> Yep, but then it is no longer unconfined_t, and how will you
> subsequently update those files?
> 
> > Also, in this particular case, the file in question is owned by root
> > with the setuid bit set, so limiting execute permissions is more
> > important. When a non-root user copies a file with the setuid bit
set,
> > the copy of the file does not retain the setuid bit.
> 
> But now you are relying on DAC for your actual protection.
> 
> > Unconfined uses the file_type attribute rather than the exec_type
> > attribute to get execute privilege to all executables (why?).
> 
> files.if defines the interface for gaining unconfined access to all
> files, and files.te implements that by allowing all permissions
between
> such domains and all file types.  All permissions, including execute.
> But write and relabelto are no less important.
> 
> >  I know
> > this because I added a neverallow rule (neverallow unconfined_t
> > my_exec_t:file execute), and then eliminated the call to
> > domain_entry_file, and I still got a compile error resulting from
the
> > neverallow rule. However, if I remove the call to files_type, then
it
> > compiles fine. This eliminates all access to the file from the
> > unconfined_t domain. Will there be any bad side effects to
eliminating
> > the file_type attribute to my_exec_t? Is there really no better way
to
> > accomplish this?
> 
> Without file_type, you won't be allowed to create or relabel files
with
> that type (associate check).
> 
> Better way is to create a separate domain that is restricted, then
> assign your users to it instead of unconfined_t, only letting root use
> unconfined_t.  That's the model for the merged targeted+strict policy,
I
> think, that is being created in rawhide / Fedora 8.
> 
> --
> Stephen Smalley
> National Security Agency




--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: confining the unconfined_t domain

[Daniel J Walsh]

Clarkson, Mike R (US SSA) wrote:
>   
>> -----Original Message-----
>> From: Stephen Smalley [mailto:sds@tycho.nsa.gov]
>> Sent: Thursday, August 16, 2007 2:15 PM
>> To: Clarkson, Mike R (US SSA)
>> Cc: selinux@tycho.nsa.gov; Daniel J Walsh
>> Subject: RE: confining the unconfined_t domain
>>
>> On Thu, 2007-08-16 at 13:37 -0700, Clarkson, Mike R (US SSA) wrote:
>>     
>>>> -----Original Message-----
>>>> From: Stephen Smalley [mailto:sds@tycho.nsa.gov]
>>>> Sent: Thursday, August 16, 2007 11:07 AM
>>>> To: Clarkson, Mike R (US SSA)
>>>> Cc: selinux@tycho.nsa.gov
>>>> Subject: Re: confining the unconfined_t domain
>>>>
>>>> On Thu, 2007-08-16 at 10:15 -0700, Clarkson, Mike R (US SSA)
>>>>         
> wrote:
>   
>>>>> I'd like to prevent the unconfined_t domain from executing
>>>>>           
> certain
>   
>>> files
>>>       
>>>>> associated with domains that I've added. What is the best way to
>>>>>           
> do
>   
>>>>> this?
>>>>>
>>>>> I was trying to track down how the unconfined_t domain is given
>>>>>           
> the
>   
>>>>> executable permissions to all executable files. I assume it is
>>>>>           
>>> through
>>>       
>>>>> the  exec_type attribute somehow. I found the
>>>>> corecmd_exec_all_executables and corecmd_mmap_all_executables
>>>>>           
>>> interfaces
>>>       
>>>>> in corecommands.if, which both give execute privilege to
>>>>>           
> exec_type,
>   
>>> but
>>>       
>>>>> I don't see these being called from the unconfined module. Can
>>>>>           
>>> someone
>>>       
>>>>> point out how this privilege is provided to the unconfined_t
>>>>>           
> domain?
>   
>>>> Um, unconfined_t is "unconfined".  By definition.
>>>>
>>>> And removing the ability to execute another program doesn't change
>>>>         
>>> what
>>>       
>>>> unconfined_t can do (i.e. its actual permissions); it can always
>>>>         
>>> create
>>>       
>>>> its own copy of the same code and execute it in unconfined_t.
>>>>
>>>> Use a different domain if you want it to be confined.
>>>>         
>>> I recognize that it would be better to use the strict policy so that
>>>       
> we
>   
>>> didn't have an unconfined_t domain, and we plan to switch in the
>>>       
> future
>   
>>> before going to operations, but for now we're using the targeted
>>>       
> policy
>   
>>> while in a prototype phase with an upcoming demo.
>>>       
>> It doesn't matter what policy you use (targeted or strict); you just
>> can't reasonably restrict unconfined_t without doing major surgery on
>> it, and then you have the further problem of once having done major
>> surgery on it, you no longer have a domain from which you can do admin
>> tasks.  Better to introduce a separate domain and use it instead.
>>     
>
> I think there may be a fairly simple way to restrict the unconfined_t
> domain from having access to specified files. I added an attribute to
> files.te called always_confined_type, as well as an interface to
> files.if to assign this attribute to a given file type. Then I modified
> files.te as follows to use the always_confined_type attribute:
>
> ########################################
> #
> # Unconfined access to this module
> #
>
> # Create/access any file in a labeled filesystem;
> allow files_unconfined_type {file_type -always_confined_type}:{ file
> chr_file } ~execmod;
> allow files_unconfined_type {file_type -always_confined_type}:{ dir
> lnk_file sock_file fifo_file blk_file } *;
>
> # Mount/unmount any filesystem with the context= option. 
> allow files_unconfined_type {file_type -always_confined_type}:filesystem
> *;
>
> ifdef(`targeted_policy',`
> 	tunable_policy(`allow_execmod',`
> 		allow files_unconfined_type {file_type
> -always_confined_type}:file execmod;
> 	')
> ')
>
> This denies all access to the file type given the always_confined_type
> attribute, so if you want to be able to do anything with that file type,
> you'll have to do from some domain which has been explicitly granted
> appropriate permissions.
>
> Do you see any problems with this approach?
>
>   
Well it is still fairly easily gotten around.

setenforce 0
Build an rpm package that overwrites them
Build a policy module that gives me this privs,
Use fstools or other apps to write over the files.
...
How do my backup utilities work.  Can I use them to subvert your protection.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: confining the unconfined_t domain

[Clarkson, Mike R (US SSA)]

> -----Original Message-----
> From: Daniel J Walsh [mailto:dwalsh@redhat.com]
> Sent: Tuesday, August 21, 2007 2:05 PM
> To: Clarkson, Mike R (US SSA)
> Cc: Stephen Smalley; selinux@tycho.nsa.gov
> Subject: Re: confining the unconfined_t domain
> 
> Clarkson, Mike R (US SSA) wrote:
> >
> >> -----Original Message-----
> >> From: Stephen Smalley [mailto:sds@tycho.nsa.gov]
> >> Sent: Thursday, August 16, 2007 2:15 PM
> >> To: Clarkson, Mike R (US SSA)
> >> Cc: selinux@tycho.nsa.gov; Daniel J Walsh
> >> Subject: RE: confining the unconfined_t domain
> >>
> >> On Thu, 2007-08-16 at 13:37 -0700, Clarkson, Mike R (US SSA) wrote:
> >>
> >>>> -----Original Message-----
> >>>> From: Stephen Smalley [mailto:sds@tycho.nsa.gov]
> >>>> Sent: Thursday, August 16, 2007 11:07 AM
> >>>> To: Clarkson, Mike R (US SSA)
> >>>> Cc: selinux@tycho.nsa.gov
> >>>> Subject: Re: confining the unconfined_t domain
> >>>>
> >>>> On Thu, 2007-08-16 at 10:15 -0700, Clarkson, Mike R (US SSA)
> >>>>
> > wrote:
> >
> >>>>> I'd like to prevent the unconfined_t domain from executing
> >>>>>
> > certain
> >
> >>> files
> >>>
> >>>>> associated with domains that I've added. What is the best way to
> >>>>>
> > do
> >
> >>>>> this?
> >>>>>
> >>>>> I was trying to track down how the unconfined_t domain is given
> >>>>>
> > the
> >
> >>>>> executable permissions to all executable files. I assume it is
> >>>>>
> >>> through
> >>>
> >>>>> the  exec_type attribute somehow. I found the
> >>>>> corecmd_exec_all_executables and corecmd_mmap_all_executables
> >>>>>
> >>> interfaces
> >>>
> >>>>> in corecommands.if, which both give execute privilege to
> >>>>>
> > exec_type,
> >
> >>> but
> >>>
> >>>>> I don't see these being called from the unconfined module. Can
> >>>>>
> >>> someone
> >>>
> >>>>> point out how this privilege is provided to the unconfined_t
> >>>>>
> > domain?
> >
> >>>> Um, unconfined_t is "unconfined".  By definition.
> >>>>
> >>>> And removing the ability to execute another program doesn't
change
> >>>>
> >>> what
> >>>
> >>>> unconfined_t can do (i.e. its actual permissions); it can always
> >>>>
> >>> create
> >>>
> >>>> its own copy of the same code and execute it in unconfined_t.
> >>>>
> >>>> Use a different domain if you want it to be confined.
> >>>>
> >>> I recognize that it would be better to use the strict policy so
that
> >>>
> > we
> >
> >>> didn't have an unconfined_t domain, and we plan to switch in the
> >>>
> > future
> >
> >>> before going to operations, but for now we're using the targeted
> >>>
> > policy
> >
> >>> while in a prototype phase with an upcoming demo.
> >>>
> >> It doesn't matter what policy you use (targeted or strict); you
just
> >> can't reasonably restrict unconfined_t without doing major surgery
on
> >> it, and then you have the further problem of once having done major
> >> surgery on it, you no longer have a domain from which you can do
admin
> >> tasks.  Better to introduce a separate domain and use it instead.
> >>
> >
> > I think there may be a fairly simple way to restrict the
unconfined_t
> > domain from having access to specified files. I added an attribute
to
> > files.te called always_confined_type, as well as an interface to
> > files.if to assign this attribute to a given file type. Then I
modified
> > files.te as follows to use the always_confined_type attribute:
> >
> > ########################################
> > #
> > # Unconfined access to this module
> > #
> >
> > # Create/access any file in a labeled filesystem;
> > allow files_unconfined_type {file_type -always_confined_type}:{ file
> > chr_file } ~execmod;
> > allow files_unconfined_type {file_type -always_confined_type}:{ dir
> > lnk_file sock_file fifo_file blk_file } *;
> >
> > # Mount/unmount any filesystem with the context= option.
> > allow files_unconfined_type {file_type
-always_confined_type}:filesystem
> > *;
> >
> > ifdef(`targeted_policy',`
> > 	tunable_policy(`allow_execmod',`
> > 		allow files_unconfined_type {file_type
> > -always_confined_type}:file execmod;
> > 	')
> > ')
> >
> > This denies all access to the file type given the
always_confined_type
> > attribute, so if you want to be able to do anything with that file
type,
> > you'll have to do from some domain which has been explicitly granted
> > appropriate permissions.
> >
> > Do you see any problems with this approach?
> >
> >
> Well it is still fairly easily gotten around.
> 
> setenforce 0
> Build an rpm package that overwrites them
> Build a policy module that gives me this privs,
> Use fstools or other apps to write over the files.
> ...
> How do my backup utilities work.  Can I use them to subvert your
> protection.

I'm not sure that putting SELinux in permissive mode is playing fair.
Does SELinux provide much if any protection against attackers who have
the ability to do that?

The backup utilities would have to be granted the specific privileges
needed to make backup copies. In this case only read privileges would be
provided, no write, execute, or relabel privileges. The main point is
that for types given the always_confined_type attribute, only domains
that have been explicitly granted privileges to the type have any access
to it, as opposed to every unconfined domain having complete access to
it.



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: confining the unconfined_t domain

[Daniel J Walsh]

Clarkson, Mike R (US SSA) wrote:
>   
>> -----Original Message-----
>> From: Daniel J Walsh [mailto:dwalsh@redhat.com]
>> Sent: Tuesday, August 21, 2007 2:05 PM
>> To: Clarkson, Mike R (US SSA)
>> Cc: Stephen Smalley; selinux@tycho.nsa.gov
>> Subject: Re: confining the unconfined_t domain
>>
>> Clarkson, Mike R (US SSA) wrote:
>>     
>>>> -----Original Message-----
>>>> From: Stephen Smalley [mailto:sds@tycho.nsa.gov]
>>>> Sent: Thursday, August 16, 2007 2:15 PM
>>>> To: Clarkson, Mike R (US SSA)
>>>> Cc: selinux@tycho.nsa.gov; Daniel J Walsh
>>>> Subject: RE: confining the unconfined_t domain
>>>>
>>>> On Thu, 2007-08-16 at 13:37 -0700, Clarkson, Mike R (US SSA) wrote:
>>>>
>>>>         
>>>>>> -----Original Message-----
>>>>>> From: Stephen Smalley [mailto:sds@tycho.nsa.gov]
>>>>>> Sent: Thursday, August 16, 2007 11:07 AM
>>>>>> To: Clarkson, Mike R (US SSA)
>>>>>> Cc: selinux@tycho.nsa.gov
>>>>>> Subject: Re: confining the unconfined_t domain
>>>>>>
>>>>>> On Thu, 2007-08-16 at 10:15 -0700, Clarkson, Mike R (US SSA)
>>>>>>
>>>>>>             
>>> wrote:
>>>
>>>       
>>>>>>> I'd like to prevent the unconfined_t domain from executing
>>>>>>>
>>>>>>>               
>>> certain
>>>
>>>       
>>>>> files
>>>>>
>>>>>           
>>>>>>> associated with domains that I've added. What is the best way to
>>>>>>>
>>>>>>>               
>>> do
>>>
>>>       
>>>>>>> this?
>>>>>>>
>>>>>>> I was trying to track down how the unconfined_t domain is given
>>>>>>>
>>>>>>>               
>>> the
>>>
>>>       
>>>>>>> executable permissions to all executable files. I assume it is
>>>>>>>
>>>>>>>               
>>>>> through
>>>>>
>>>>>           
>>>>>>> the  exec_type attribute somehow. I found the
>>>>>>> corecmd_exec_all_executables and corecmd_mmap_all_executables
>>>>>>>
>>>>>>>               
>>>>> interfaces
>>>>>
>>>>>           
>>>>>>> in corecommands.if, which both give execute privilege to
>>>>>>>
>>>>>>>               
>>> exec_type,
>>>
>>>       
>>>>> but
>>>>>
>>>>>           
>>>>>>> I don't see these being called from the unconfined module. Can
>>>>>>>
>>>>>>>               
>>>>> someone
>>>>>
>>>>>           
>>>>>>> point out how this privilege is provided to the unconfined_t
>>>>>>>
>>>>>>>               
>>> domain?
>>>
>>>       
>>>>>> Um, unconfined_t is "unconfined".  By definition.
>>>>>>
>>>>>> And removing the ability to execute another program doesn't
>>>>>>             
> change
>   
>>>>> what
>>>>>
>>>>>           
>>>>>> unconfined_t can do (i.e. its actual permissions); it can always
>>>>>>
>>>>>>             
>>>>> create
>>>>>
>>>>>           
>>>>>> its own copy of the same code and execute it in unconfined_t.
>>>>>>
>>>>>> Use a different domain if you want it to be confined.
>>>>>>
>>>>>>             
>>>>> I recognize that it would be better to use the strict policy so
>>>>>           
> that
>   
>>> we
>>>
>>>       
>>>>> didn't have an unconfined_t domain, and we plan to switch in the
>>>>>
>>>>>           
>>> future
>>>
>>>       
>>>>> before going to operations, but for now we're using the targeted
>>>>>
>>>>>           
>>> policy
>>>
>>>       
>>>>> while in a prototype phase with an upcoming demo.
>>>>>
>>>>>           
>>>> It doesn't matter what policy you use (targeted or strict); you
>>>>         
> just
>   
>>>> can't reasonably restrict unconfined_t without doing major surgery
>>>>         
> on
>   
>>>> it, and then you have the further problem of once having done major
>>>> surgery on it, you no longer have a domain from which you can do
>>>>         
> admin
>   
>>>> tasks.  Better to introduce a separate domain and use it instead.
>>>>
>>>>         
>>> I think there may be a fairly simple way to restrict the
>>>       
> unconfined_t
>   
>>> domain from having access to specified files. I added an attribute
>>>       
> to
>   
>>> files.te called always_confined_type, as well as an interface to
>>> files.if to assign this attribute to a given file type. Then I
>>>       
> modified
>   
>>> files.te as follows to use the always_confined_type attribute:
>>>
>>> ########################################
>>> #
>>> # Unconfined access to this module
>>> #
>>>
>>> # Create/access any file in a labeled filesystem;
>>> allow files_unconfined_type {file_type -always_confined_type}:{ file
>>> chr_file } ~execmod;
>>> allow files_unconfined_type {file_type -always_confined_type}:{ dir
>>> lnk_file sock_file fifo_file blk_file } *;
>>>
>>> # Mount/unmount any filesystem with the context= option.
>>> allow files_unconfined_type {file_type
>>>       
> -always_confined_type}:filesystem
>   
>>> *;
>>>
>>> ifdef(`targeted_policy',`
>>> 	tunable_policy(`allow_execmod',`
>>> 		allow files_unconfined_type {file_type
>>> -always_confined_type}:file execmod;
>>> 	')
>>> ')
>>>
>>> This denies all access to the file type given the
>>>       
> always_confined_type
>   
>>> attribute, so if you want to be able to do anything with that file
>>>       
> type,
>   
>>> you'll have to do from some domain which has been explicitly granted
>>> appropriate permissions.
>>>
>>> Do you see any problems with this approach?
>>>
>>>
>>>       
>> Well it is still fairly easily gotten around.
>>
>> setenforce 0
>> Build an rpm package that overwrites them
>> Build a policy module that gives me this privs,
>> Use fstools or other apps to write over the files.
>> ...
>> How do my backup utilities work.  Can I use them to subvert your
>> protection.
>>     
>
> I'm not sure that putting SELinux in permissive mode is playing fair.
> Does SELinux provide much if any protection against attackers who have
> the ability to do that?
>
> The backup utilities would have to be granted the specific privileges
> needed to make backup copies. In this case only read privileges would be
> provided, no write, execute, or relabel privileges. The main point is
> that for types given the always_confined_type attribute, only domains
> that have been explicitly granted privileges to the type have any access
> to it, as opposed to every unconfined domain having complete access to
> it.
>
>
>
> --
> This message was distributed to subscribers of the selinux mailing list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.
>   
I think it could, secure_mode_* booleans go some of the way towards 
doing this, They prevent the inserting of kernel modules.   The problem 
here as you probably know, is you are trying to guess all the possible 
ways a super privledged user could attack you.   SELinux is better at 
defining what a user can do, then trying to define what they can not do, 
and then plugging all the holes.
circumvent your protection, which is difficult/impossible to do.
do it in strict policy.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.