3:52 a.m.
Is there is a simple libselinux call I can make in httpd to determine
whether or not the SELinux policy is enabled and applied?
I'd like to add a one-line notice to the default error_log when it is,
to give an obvious tip-off to confused new users.
joe
7:35 a.m.
On Thu, 2005-11-03 at 09:52 +0000, Joe Orton wrote:
Is there is a simple libselinux call I can make in httpd to determine
whether or not the SELinux policy is enabled and applied?
I'd like to add a one-line notice to the default error_log when it is,
to give an obvious tip-off to confused new users.
is_selinux_enabled() will return > 0 if SELinux is enabled.
getcon(&con) will set con to the context in which the process is
running.
--
Stephen Smalley
National Security Agency
8:06 a.m.
Joe Orton wrote:
Is there is a simple libselinux call I can make in httpd to determine
whether or not the SELinux policy is enabled and applied?
I'd like to add a one-line notice to the default error_log when it is,
to give an obvious tip-off to confused new users.
I am not sure what you want. You can ask whether SELinux is enabled.
is_selinux_enabled(), or you can getcon to get the current context.
So you could show that the context is system_u:system_r:httpd_t in the
log file if getcon is called.
joe
--
fedora-selinux-list mailing list
fedora-selinux-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
--
8:24 a.m.
On Thu, Nov 03, 2005 at 08:35:56AM -0500, Stephen Smalley wrote:
On Thu, 2005-11-03 at 09:52 +0000, Joe Orton wrote:
> Is there is a simple libselinux call I can make in httpd to determine
> whether or not the SELinux policy is enabled and applied?
>
> I'd like to add a one-line notice to the default error_log when it is,
> to give an obvious tip-off to confused new users.
is_selinux_enabled() will return > 0 if SELinux is enabled.
getcon(&con) will set con to the context in which the process is
running.
Great, thanks. Is it OK to presume that security_context_t is always a
char * and just print that string?
joe
8:39 a.m.
On Thu, 2005-11-03 at 09:49 -0500, Ivan Gyurdiev wrote:
Stephen Smalley wrote:
> On Thu, 2005-11-03 at 14:24 +0000, Joe Orton wrote:
>
>> Great, thanks. Is it OK to presume that security_context_t is always a
>> char * and just print that string?
>>
>
> Yes.
>
The natural followup question is - why is security_context_t being used,
instead of char* ?
Fair question, but removing the typedef now would be rather painful. In
any event, they are strings and are handled as such by the existing
SELinux patches to userland. We just don't want applications making
assumptions about the internal format of the strings; they should always
use the libselinux context_* functions to get/set individual fields of
the context if they need to do that.
--
Stephen Smalley
National Security Agency
8:49 a.m.
Stephen Smalley wrote:
On Thu, 2005-11-03 at 14:24 +0000, Joe Orton wrote:
> Great, thanks. Is it OK to presume that security_context_t is always a
> char * and just print that string?
>
Yes.
The natural followup question is - why is security_context_t being used,
instead of char* ?
9:05 a.m.
>>> Great, thanks. Is it OK to presume that security_context_t is always a
>>> char * and just print that string?
>>>
>>>
>> Yes.
>>
>>
> The natural followup question is - why is security_context_t being used,
> instead of char* ?
>
Fair question, but removing the typedef now would be rather painful. In
any event, they are strings and are handled as such by the existing
SELinux patches to userland. We just don't want applications making
assumptions about the internal format of the strings; they should always
use the libselinux context_* functions to get/set individual fields of
the context if they need to do that.
Chances are that if something's possible without a warning, someone will
eventually do it...
Also, it seems rather confusing to me to have two data structures for
the same thing
(not to mention the 2+ other ones used in sepol/semanage).
9:14 a.m.
On Thu, 2005-11-03 at 10:05 -0500, Ivan Gyurdiev wrote:
Chances are that if something's possible without a warning,
someone will
eventually do it...
Also, it seems rather confusing to me to have two data structures for
the same thing
(not to mention the 2+ other ones used in sepol/semanage).
Hysterical raisins, er historical reasons.
security_context_t was the original type, a string representation of the
security attributes that could be handled by the kernel and applications
without tying them to a specific security model. Only the security
server could truly interpret the content (relative to a given policy),
and only SELinux code (libselinux or kernel security server) could even
interpret the format (e.g. breaking out the fields).
The separate context structure type was introduced to allow
security-aware applications to further manipulate the individual fields
without needing to know the internal format of the string. Naturally,
you can extract the string from the structure, so one could have then
replaced all direct uses of the string with the struct, but I don't
think that would be optimal; plenty of applications only want to deal
with the string. ls -Z, ps -Z, mkdir -Z, ...
As you know, libsepol was a much later creation from the core
checkpolicy code (which in turn was derived from the security server
code), and is for policy manipulation rather than interacting with the
SELinux kernel.
--
Stephen Smalley
National Security Agency
9:43 a.m.
On Thu, 2005-11-03 at 10:45 -0500, Ivan Gyurdiev wrote:
Stephen Smalley wrote:
Naturally,
> you can extract the string from the structure, so one could have then
> replaced all direct uses of the string with the struct, but I don't
> think that would be optimal; plenty of applications only want to deal
> with the string. ls -Z, ps -Z, mkdir -Z, ...
>
So, there should be convert functions to go from one to the other, and the
library interfaces should work with the opaque structure, not with the
string.
I don't think so. Consider: today, ls can call getfilecon(), which
internally performs a getxattr(), which returns the string stored in the
attribute value, and returns it back to ls for display to the user. Why
force that process to go through an extra conversion to struct and back
for no reason?
Anyway, I'm not volunteering to do this right now - just making
some
observations.
--
Stephen Smalley
National Security Agency
9:45 a.m.
Stephen Smalley wrote:
On Thu, 2005-11-03 at 10:05 -0500, Ivan Gyurdiev wrote:
> Chances are that if something's possible without a warning, someone will
> eventually do it...
> Also, it seems rather confusing to me to have two data structures for
> the same thing
> (not to mention the 2+ other ones used in sepol/semanage).
>
Hysterical raisins, er historical reasons.
Someone should write a bug, er...book on the history of SELinux...
It's fascinating how much code exists purely for historical
considerations :)
The separate context structure type was introduced to allow
security-aware applications to further manipulate the individual fields
without needing to know the internal format of the string. Naturally,
you can extract the string from the structure, so one could have then
replaced all direct uses of the string with the struct, but I don't
think that would be optimal; plenty of applications only want to deal
with the string. ls -Z, ps -Z, mkdir -Z, ...
So, there should be convert functions to go from one to the other, and the
library interfaces should work with the opaque structure, not with the
string.
Anyway, I'm not volunteering to do this right now - just making some
observations.
10:15 a.m.
I don't think so. Consider: today, ls can call getfilecon(), which
internally performs a getxattr(), which returns the string stored in the
attribute value, and returns it back to ls for display to the user. Why
force that process to go through an extra conversion to struct and back
for no reason?
You could still store it as a string, instead of piecewise, and then
extract fields on demand, when set() or get() is called. Then the
conversion can be done as a cast for users that want the whole string.
Anyway I haven't thought much about this problem, as optimization and
data hiding are usually the opposite of each other.. but there's
probably a way to combine them...
7:59 a.m.
On Thu, 2005-11-03 at 11:15 -0500, Ivan Gyurdiev wrote:
>
> I don't think so. Consider: today, ls can call getfilecon(), which
> internally performs a getxattr(), which returns the string stored in the
> attribute value, and returns it back to ls for display to the user. Why
> force that process to go through an extra conversion to struct and back
> for no reason?
>
You could still store it as a string, instead of piecewise, and then
extract fields on demand, when set() or get() is called. Then the
conversion can be done as a cast for users that want the whole string.
Anyway I haven't thought much about this problem, as optimization and
data hiding are usually the opposite of each other.. but there's
probably a way to combine them...
But the question is still why do so? You gain nothing from such "data
hiding" in this case, as the application still ends up converting to
string form and can still violate the "encapsulation" at that point by
peeking inside the string. It ends up being no different from directly
returning the string form in that case as far as "data hiding" is
concerned, and the string form is what most users of libselinux want.
The structure is for a minority of users of libselinux that actually
care about the individual fields.
--
Stephen Smalley
National Security Agency
8:07 a.m.
On Fri, 2005-11-04 at 08:59 -0500, Stephen Smalley wrote:
But the question is still why do so? You gain nothing from such
"data
hiding" in this case, as the application still ends up converting to
string form and can still violate the "encapsulation" at that point by
peeking inside the string. It ends up being no different from directly
returning the string form in that case as far as "data hiding" is
concerned, and the string form is what most users of libselinux want.
The structure is for a minority of users of libselinux that actually
care about the individual fields.
So, in summary, the libselinux interface is exactly right - most of its
interfaces operate on the abstraction/data type that is most commonly
needed by its users, and it provides separate conversion and
manipulation functions for the minority of users that need to operate on
the structured form. The only mistake was bothering to create a typedef
for security_context_t versus just using char* everywhere.
--
Stephen Smalley
National Security Agency
6746
days inactive
6747
days old
selinux@lists.fedoraproject.org
13 comments
4 participants
participants (4)
-
Daniel J Walsh -
Ivan Gyurdiev -
Joe Orton -
Stephen Smalley