[refpolicy] I think we made a large mistake when we designed apache_content_template.

[refpolicy] I think we made a large mistake when we designed apache_content_template.

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

	type httpd_$1_content_t; # customizable;
	typeattribute httpd_$1_content_t httpd_content_type;
	typealias httpd_$1_content_t alias httpd_$1_script_ro_t;
	files_type(httpd_$1_content_t)

	# This type is used for .htaccess files
	type httpd_$1_htaccess_t, httpd_content_type; # customizable;
	typeattribute httpd_$1_htaccess_t httpd_content_type;
	files_type(httpd_$1_htaccess_t)

THe problem I believe is we prefix the types with httpd_, I would like to
remove this and change the code to something like


	type $1_http_content_t; # customizable;
	typeattribute $1_http_content_t httpd_content_type;
	files_type($1_http_content_t)

	# This type is used for .htaccess files
	type $1_http_htaccess_t, httpd_content_type; # customizable;
	typeattribute $1_http_htaccess_t httpd_content_type;
	files_type($1_http_htaccess_t)

	# Type that CGI scripts run as
	type $1_cgi_t,	httpd_script_type;
	domain_type($1_cgi_t)
	role system_r types $1_cgi_t;	
	type $1_cgi_exec_t, httpd_script_exec_type; # customizable;
	typeattribute $1_cgi_exec_t httpd_content_type;
	typeattribute httpd_$1_rw_content_t httpd_content_type;

	typealias $1_http_rw_content_t alias { httpd_$1_script_rw_t
httpd_$1_content_rw_t };
	files_type($1_http_rw_content_t)

...

Then tools can look for all content which begins bugzilla and have the correct
types drawn.

http://danwalsh.livejournal.com/67007.html

Shows the problem of begging all apache cgi domains with httpd_

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJoDfEACgkQrlYvE4MpobMFXgCglA+7JfwUFhQ/YgBrmCDOBsfs
AJMAoJ1s5x+hOe6UHq0Mv41S6DIhxgkv
=j8Ab
-----END PGP SIGNATURE-----

[refpolicy] I think we made a large mistake when we designed apache_content_template.

[Dominick Grift]

On Wed, 2013-10-23 at 13:57 -0400, Daniel J Walsh wrote:

> ...
> 
> Then tools can look for all content which begins bugzilla and have the correct
> types drawn.
> 

I don't have any issues with this change in apache module, but i think
its a dead end because sooner or later things will break. just because
of the configurability of SELinux

The nature of SELinux is that it is configurable, and my opinion is that
user space should acknowledge this and not depend on things that are
not , or might not always, be fixed, or according to "standards". Like
how people name their identifiers

Its kind of like the issue that cgroups are facing i guess in a sense:

https://www.youtube.com/watch?v=MSG4jW187Is

A solution might be to create single handler of SELinux policy that
validates the policy. Identifiers that do not meet the requirements will
be rejected by the handler (or it should not even be possible to create
identifiers that might break your tools).

This , kind of assures, that your tools can rely on the standards you
set.

Of course the handler should be eventually be optional, but fedora could
"enforce its use"  or at least encourage it.

But even then, how does one create an handler for such a flexible
framework as selinux and who is going to maintain it?

.. Maybe its better to just not let your tools make such assumptions in
the first place

[refpolicy] I think we made a large mistake when we designed apache_content_template.

[Sven Vermeulen]

On Oct 23, 2013 7:57 PM, "Daniel J Walsh" <dwalsh@redhat.com> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>         type httpd_$1_content_t; # customizable;
>         typeattribute httpd_$1_content_t httpd_content_type;
>         typealias httpd_$1_content_t alias httpd_$1_script_ro_t;
>         files_type(httpd_$1_content_t)
>
>         # This type is used for .htaccess files
>         type httpd_$1_htaccess_t, httpd_content_type; # customizable;
>         typeattribute httpd_$1_htaccess_t httpd_content_type;
>         files_type(httpd_$1_htaccess_t)
>
> THe problem I believe is we prefix the types with httpd_, I would like to
> remove this and change the code to something like
>
>
>         type $1_http_content_t; # customizable;
>         typeattribute $1_http_content_t httpd_content_type;
>         files_type($1_http_content_t)
>
>         # This type is used for .htaccess files
>         type $1_http_htaccess_t, httpd_content_type; # customizable;
>         typeattribute $1_http_htaccess_t httpd_content_type;
>         files_type($1_http_htaccess_t)
>
>         # Type that CGI scripts run as
>         type $1_cgi_t,  httpd_script_type;
>         domain_type($1_cgi_t)
>         role system_r types $1_cgi_t;
>         type $1_cgi_exec_t, httpd_script_exec_type; # customizable;
>         typeattribute $1_cgi_exec_t httpd_content_type;
>         typeattribute httpd_$1_rw_content_t httpd_content_type;
>
>         typealias $1_http_rw_content_t alias { httpd_$1_script_rw_t
> httpd_$1_content_rw_t };
>         files_type($1_http_rw_content_t)
>
> ...
>
> Then tools can look for all content which begins bugzilla and have the
correct
> types drawn.
>
> http://danwalsh.livejournal.com/67007.html
>
> Shows the problem of begging all apache cgi domains with httpd_

Is it sensible to assume such logic in type names? It also works
vice-versa: not having web content (or http-related) starting with httpd_
suddenly might trigger similar "issues".

If we would do so though, I expect that we can use aliases for the duration
of one or two major releases?

But another thought: isn't it sufficient to base logic on attributes here?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20131023/3ebe3473/attachment.html 

[refpolicy] I think we made a large mistake when we designed apache_content_template.

[Dominick Grift]

On Wed, 2013-10-23 at 21:14 +0200, Sven Vermeulen wrote:

> 
> But another thought: isn't it sufficient to base logic on attributes here?

Boolean identifiers are just as configurable as any other identifiers

The only thing you can rely on is access vectors, and keywords

You cannot do as much with those as you could, in theory, with the
addition of identifiers

> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy

[refpolicy] I think we made a large mistake when we designed apache_content_template.

[Dominick Grift]

On Wed, 2013-10-23 at 21:29 +0200, Dominick Grift wrote:
> On Wed, 2013-10-23 at 21:14 +0200, Sven Vermeulen wrote:
> 
> > 
> > But another thought: isn't it sufficient to base logic on attributes here?
> 
> Boolean identifiers are just as configurable as any other identifiers

Err, i meant attribute identifiers obviously

[refpolicy] I think we made a large mistake when we designed apache_content_template.

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/23/2013 03:29 PM, Dominick Grift wrote:
> On Wed, 2013-10-23 at 21:14 +0200, Sven Vermeulen wrote:
> 
>> 
>> But another thought: isn't it sufficient to base logic on attributes
>> here?
> 
> Boolean identifiers are just as configurable as any other identifiers
> 
> The only thing you can rely on is access vectors, and keywords
> 
> You cannot do as much with those as you could, in theory, with the addition
> of identifiers
> 
>> _______________________________________________ refpolicy mailing list 
>> refpolicy at oss.tresys.com 
>> http://oss.tresys.com/mailman/listinfo/refpolicy
> 
> 
Yes I think we could attempt to do all of these things, and I agree that it is
somwhat flimsy, but it is the best we have right now.

In Fedora right now we have

seinfo -t | awk '{ print $1 }'| grep ^http | wc -l
183

One potential idea would be to have the tooling create an attribute based on
the module name (Not good for non Modular policy).  Then we could assign the
attribute to all types defined within the module.

httpd_module_attribue for example.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJoJkQACgkQrlYvE4MpobOhJwCbB5SQp0FncpZFkffvKlikh6jn
zqQAnRFWEZmRRhCyFmHO2AGpN8czOWPs
=YJx1
-----END PGP SIGNATURE-----

[refpolicy] I think we made a large mistake when we designed apache_content_template.

[Dominick Grift]

On Wed, 2013-10-23 at 13:57 -0400, Daniel J Walsh wrote:
> 	type httpd_$1_content_t; # customizable;

> 
> Then tools can look for all content which begins bugzilla and have the correct
> types drawn.

How about one teaches ones tool to use seinfo and sesearch instead?

Depending on the policy model it might not even be an issue to label
files with process type ( although i does not make sense to do it )

But its just a property of the policy you are using

People might have a policy implemented that has different properties,
and a meaningful tool would have the ability to determine
characteristics no matter what the policies properties are

[refpolicy] I think we made a large mistake when we designed apache_content_template.

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/23/2013 03:38 PM, Dominick Grift wrote:
> On Wed, 2013-10-23 at 13:57 -0400, Daniel J Walsh wrote:
>> type httpd_$1_content_t; # customizable;
> 
>> 
>> Then tools can look for all content which begins bugzilla and have the
>> correct types drawn.
> 
> How about one teaches ones tool to use seinfo and sesearch instead?
> 
> Depending on the policy model it might not even be an issue to label files
> with process type ( although i does not make sense to do it )
> 
> But its just a property of the policy you are using
> 
> People might have a policy implemented that has different properties, and a
> meaningful tool would have the ability to determine characteristics no
> matter what the policies properties are
> 
> 
Well we do have some tooling that understands seinfo and sesearch.

But the ability for xyz_t to write to abc_file_t and xyz_file_t are probably
two different concepts.  By convention is is more likely that we would want to
have a man page generated mentioning the relationship between xyz_t process
type and xyz_file_t, but ignore abc_file_t, or at least treat it as a second
class relationship.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJoJwAACgkQrlYvE4MpobMoywCg5g2mfK+XFIcBhd5/w+gHP68u
mkUAoOpChzHM4LBZroz6hHjLxApiEx6r
=H8Le
-----END PGP SIGNATURE-----

[refpolicy] I think we made a large mistake when we designed apache_content_template.

[Dominick Grift]

On Wed, 2013-10-23 at 15:44 -0400, Daniel J Walsh wrote:

> > 
> Well we do have some tooling that understands seinfo and sesearch.
> 
> But the ability for xyz_t to write to abc_file_t and xyz_file_t are probably
> two different concepts.  By convention is is more likely that we would want to
> have a man page generated mentioning the relationship between xyz_t process
> type and xyz_file_t, but ignore abc_file_t, or at least treat it as a second
> class relationship.

Yes, its just a tough issue

Heres another one of my brainstorm sessions ( brace yourselfs :P)

identifiers are configurable ( this was probably done for a reason ), If
we want our users to really use selinux, we better expect them to "break
our rules"

We can create a "primary control" of the policy but then we probably
give up much of SELinuxes flexibility, and configurability.

But then again the "primary control" would be optional, and so "power"
users could just opt-out. They do not need a tool to tell them what not
to do (Come to think about it, relying on a tool for security seems like
a sub-optimal idea to me)

I think CIL could be a great opportunity build a "primary control" on.
Its flexible, powerful, no pre-processing,, and everything can be
changed on the fly because the policy is in plain text on the system
probably

so you would get: primary-control -> cil -> selinux

keep the primary control as flexible as possible, only make it enforce,
strictly what we need it to enforce

So i think there are two things to tackle here

(ref|cil)policy 3.0:

back to the basics: only provide, maintain a solid base, no contrib

this base should be a base for all, and it should be made with cil|
primary control in mind

primary-control 1.0:

The ultimate policy ide, its like slide on steriods. it will enforce
standards and will be the primary interface with cil/selinux

It will not be a policy wizard ( click through menus ) and it will be as
flexible as possible, enforce as little as possible, but it will be made
so that tools can rely on certain standards

Then i guess we should make it so that the policy can be manipulated
only via primary control to ensure that one doesnt by pass it (unless
admin configures things explicity to not use primary control in which
case admin understands that tools that rely on primary control 1.0 and
ref|cilpolicy 3.0 will break. (for power users thats not a problem
anyways as long as we do not shut them out (e.g. we give both scenarios
attention. not neglect the power users ( like one neglected monolithic
policy when one implemented modular policy )