Question on unconfined_t

Question on unconfined_t

[Paddie O'Brien]

Hi,

As a learning exercise I created a simple policy to sandbox a simple
program in its own domain.

I had to add rules to the policy to allow the program to be executed
from unconfined_t. Is this normal? My understanding was that a process
in unconfined_t was subject only to DAC so why did I have to add this
rule? What does unconfined_t actually mean?

Thanks.

Re: Question on unconfined_t

[Stephen Smalley]

On 11/17/2014 09:44 AM, Paddie O'Brien wrote:
> Hi,
> 
> As a learning exercise I created a simple policy to sandbox a simple
> program in its own domain.
> 
> I had to add rules to the policy to allow the program to be executed
> from unconfined_t. Is this normal? My understanding was that a process
> in unconfined_t was subject only to DAC so why did I have to add this
> rule? What does unconfined_t actually mean?

SELinux has no intrinsic concept of unconfined_t; unconfined_t is just a
type that is allowed to do most things by policy.

Re: Question on unconfined_t

[Daniel J Walsh]

On 11/17/2014 10:37 AM, Stephen Smalley wrote:
> On 11/17/2014 09:44 AM, Paddie O'Brien wrote:
>> Hi,
>>
>> As a learning exercise I created a simple policy to sandbox a simple
>> program in its own domain.
>>
>> I had to add rules to the policy to allow the program to be executed
>> from unconfined_t. Is this normal? My understanding was that a process
>> in unconfined_t was subject only to DAC so why did I have to add this
>> rule? What does unconfined_t actually mean?
> SELinux has no intrinsic concept of unconfined_t; unconfined_t is just a
> type that is allowed to do most things by policy.
>
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
>
>
You probably did not define the type as a file_type(mytype_t)

unconfined_t is only allowed to execute file types, if you just define a
type and put it on a file, SELinux does not know if it is a port_type or
a process type (domain)
So it is not allowed.

Re: Question on unconfined_t

[Paddie O'Brien]

Thanks. I was under the mistaken impression that unconfined_t got
something for free. My new understanding is that it's by convention
that policy writers give access to unconfined_t to their domains and
they do so by adding explicit rules.

Also I was missing file_type(mytype_exec_t) although I had
domain_type(mytpe_t). Is there a way to see what things like file_type
and domain_type expand to? I want to know what's going on in the
background.

On 17 November 2014 20:37, Daniel J Walsh <dwalsh@redhat.com> wrote:
>
> On 11/17/2014 10:37 AM, Stephen Smalley wrote:
>> On 11/17/2014 09:44 AM, Paddie O'Brien wrote:
>>> Hi,
>>>
>>> As a learning exercise I created a simple policy to sandbox a simple
>>> program in its own domain.
>>>
>>> I had to add rules to the policy to allow the program to be executed
>>> from unconfined_t. Is this normal? My understanding was that a process
>>> in unconfined_t was subject only to DAC so why did I have to add this
>>> rule? What does unconfined_t actually mean?
>> SELinux has no intrinsic concept of unconfined_t; unconfined_t is just a
>> type that is allowed to do most things by policy.
>>
>> _______________________________________________
>> Selinux mailing list
>> Selinux@tycho.nsa.gov
>> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
>> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
>>
>>
> You probably did not define the type as a file_type(mytype_t)
>
> unconfined_t is only allowed to execute file types, if you just define a
> type and put it on a file, SELinux does not know if it is a port_type or
> a process type (domain)
> So it is not allowed.

Re: Question on unconfined_t

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 2522 bytes --]

On Mon, Nov 17, 2014 at 09:18:51PM +0000, Paddie O'Brien wrote:
> Thanks. I was under the mistaken impression that unconfined_t got
> something for free. My new understanding is that it's by convention
> that policy writers give access to unconfined_t to their domains and
> they do so by adding explicit rules.
> 
> Also I was missing file_type(mytype_exec_t) although I had
> domain_type(mytpe_t). Is there a way to see what things like file_type
> and domain_type expand to? I want to know what's going on in the
> background.
> 

Yes, Generally what file_type() and domain_type() do is associate a "type attribute" with the calling type

type attributes are a way to group common rules. You could look at them as tags in a way

consider this example

attribute cars

type pinto, cars;
type chevy, cars;

attribute bicycle 

type specialized, bicycle;
type cannondale, bicycle;

Now we have 4 types grouped into two categories using type attributes: cars and bicycles

now the type attributes can be used to write rules that apply to all the types associated with a particular type attribute.

allow cars i85:interstate 100mph;

stupid example that allows "all cars (pinto and chevy)" to drive 100mph on the i95 interstate

This concept of grouping types by associating type attributes with them is what is used a lot

file_type(myfile_t) associates the files_type attribute with the myfile_t type, effectively categorizing myfile_t as a type for a file
similarely domain_type(myprocess_t) categorizes myprocess_t as a type for processes

so if you want to give some type access to all "files" rather than individual types:

allow myprocess_t files_type:file read;

or if you want to allow all types associated with processes to write all types associated with files:

allow domain_type files_type:file write;

There are alot of type attributes and types (and other identifiers like roles) are grouped in many ways

To see which rules apply you can use the seinfo and sesearch command creatively.

Example:

to list all attributes: seinfo -a
to example all attributes: seinfo -xa

see which attributes are associated with the unconfined_t type: seinfo -xtunconfined_t

to see all rules associated with a particular attribute: sesearch -A -t files_type

it takes a while to get creative with those two commands and with those concepts.

Just remember selinux is like accounting in some ways, its all about grouping and associating.

-- 
Dominick Grift

[-- Attachment #2: Type: application/pgp-signature, Size: 648 bytes --]

Re: Question on unconfined_t

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 1024 bytes --]

On Mon, Nov 17, 2014 at 09:18:51PM +0000, Paddie O'Brien wrote:
> Thanks. I was under the mistaken impression that unconfined_t got
> something for free. My new understanding is that it's by convention
> that policy writers give access to unconfined_t to their domains and
> they do so by adding explicit rules.
> 
> Also I was missing file_type(mytype_exec_t) although I had
> domain_type(mytpe_t). Is there a way to see what things like file_type
> and domain_type expand to? I want to know what's going on in the
> background.
> 

Forgot the answer the actual question. You can look up what the various "macros" expand to by perusing /usr/share/selinux/devel/include if you have installed the selinux-policy-devel package
It might help a bit if you are familiar with m4. Its just macros that eventually expand to selinux policy language, sometimes the macros can nest pretty deep before you end up with the raw rules. 

macros are basically yet another way to group even more ...


-- 
Dominick Grift

[-- Attachment #2: Type: application/pgp-signature, Size: 648 bytes --]