Re: confining the unconfined_t domain

[Daniel J Walsh <dwalsh@redhat.com>]

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.