-----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-----
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
On Oct 23, 2013 7:57 PM, "Daniel J Walsh" <[email protected]> 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
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
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
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
-----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-----
-----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-----
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 )