Lets try this again: Advantages and Disadvantages of Overtyping a policy

Lets try this again: Advantages and Disadvantages of Overtyping a policy

[Dave Quigley]

Hello,
    First I would like to apologize for the empty mail before but
gmail has a silly feature of sending a mail if you hit control +
enter. While it might be useful it has quite a few downfalls.

OK onto my actual question. I was wondering what advantages and
disadvantages there are to having too many types in a policy. I can
see if you have too many the allow rules to allow interaction within
the application itself can be excessive. However it also seems to me
that by having more types for the application you can have more
control over restriction the application. You see this in come
policies where they have separate types for their files in /var /etc
and /log however you don't see it for that many applications. I would
just like to hear people's thoughts on this.

Dave Quigley

--
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: Lets try this again: Advantages and Disadvantages of Overtyping a policy

[Christopher J. PeBenito]

On Fri, 2007-02-16 at 16:08 -0500, Dave Quigley wrote:
> OK onto my actual question. I was wondering what advantages and
> disadvantages there are to having too many types in a policy. I can
> see if you have too many the allow rules to allow interaction within
> the application itself can be excessive. However it also seems to me
> that by having more types for the application you can have more
> control over restriction the application. You see this in come
> policies where they have separate types for their files in /var /etc
> and /log however you don't see it for that many applications. I would
> just like to hear people's thoughts on this.

It depends on your security goals.  The question is: does the extra
granularity help you better attain your security goals?

Take bin_t for example.  We could have a type for every single program,
but we don't because these are all system binaries that execute in the
caller's domain.  So even if the domain can execute any of the programs,
it is still limited by the access the domain has.

Something like foo_tmp_t vs. foo_log_t vs. foo_conf_t usually is
straightforward since the app will tend to have create, read, write, and
delete access for foo_tmp_t, create and append for foo_log_t, and just
read for foo_conf_t.  The objects clearly have different security
attributes, thus get different types.  Adding multiple types for each of
foo's logs would gain granularity but wouldn't gain anything
security-wise since foo still needs the same access for each type (they
have the same security attributes).

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


--
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: Lets try this again: Advantages and Disadvantages of Overtyping a policy

[Stephen Smalley]

On Tue, 2007-02-20 at 20:37 +0000, Christopher J. PeBenito wrote:
> On Fri, 2007-02-16 at 16:08 -0500, Dave Quigley wrote:
> > OK onto my actual question. I was wondering what advantages and
> > disadvantages there are to having too many types in a policy. I can
> > see if you have too many the allow rules to allow interaction within
> > the application itself can be excessive. However it also seems to me
> > that by having more types for the application you can have more
> > control over restriction the application. You see this in come
> > policies where they have separate types for their files in /var /etc
> > and /log however you don't see it for that many applications. I would
> > just like to hear people's thoughts on this.
> 
> It depends on your security goals.  The question is: does the extra
> granularity help you better attain your security goals?
> 
> Take bin_t for example.  We could have a type for every single program,
> but we don't because these are all system binaries that execute in the
> caller's domain.  So even if the domain can execute any of the programs,
> it is still limited by the access the domain has.
> 
> Something like foo_tmp_t vs. foo_log_t vs. foo_conf_t usually is
> straightforward since the app will tend to have create, read, write, and
> delete access for foo_tmp_t, create and append for foo_log_t, and just
> read for foo_conf_t.  The objects clearly have different security
> attributes, thus get different types.  Adding multiple types for each of
> foo's logs would gain granularity but wouldn't gain anything
> security-wise since foo still needs the same access for each type (they
> have the same security attributes).

Type preservation is also an issue that needs to be considered for
fine-grained typing, as policy can only distinguish based on the
creating process' domain and/or the parent directory type, so if you
have a single process creating multiple files in the same parent
directory and you want them to have different types, you need the
program to be SELinux-aware (i.e. use setfscreatecon(3)).
 
-- 
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.