Craig White wrote:
On Sun, 2006-04-02 at 09:31 +0200, A.J. Bonnema wrote:
Michael Wiktowy wrote:
I just fixed my problem with
chcon -t texrel_shlib_t /usr/lib/libsipphoneapi.so.0.78.20060211
I am not exactly sure what that does though.
Craig,
I wonder how many people do these statements without understanding the
implications? How secure would that be?
On this line, what we actually need is some kind of easifier /
dumbifier, if you get my meaning. So it is obvious what the implications
are.
----
I see your point and agree with it except that you can consider...
the target is /usr/lib/libsippphoneapi.so...
so the adjustment is made to one specific file for one specific purpose
and the whole of selinux remains intact beyond that. That is
significant.
Hmmmm, I agree that this is significant. It is quite improbable for this
file to be used for anything other than a SIP Phone.
It does take a moment of consideration if you are adding rules from say
audit2allow as some of those 'blocks' may have been caused by selinux
protections emanating from intrusion attempts and adding them either by
policy or by file context adjustment would simply open the door for
them, a slight bit of consideration should be all that is necessary to
evaluate the reason.
Per this situation, he knew that he installed the 'Gizmo' ip phone
software so it makes sense that this 'block' occurred from the software
he wants to run so taking the necessary steps to enable it make sense.
In your specific case, it would appear that you are setting up squid in
both examples that you gave, so adding the file contexts for squid would
be perfectly logical.
Okee. Let's say this is true and sound. I could add the file contexts.
Where is the boundary / limit? How do I recognize a perfectly legal and logical action and discriminate this from a potential security hole?
From your answer, I gather:
1. A modification of the SELinux policy that is limited to just 1 package is not ever a problem.
This would represent a breach in the security for that area only. An exploit could not take over my machine from this kind of error alone.
2. Any modification to the SELInux system itself (like switching off all booleans or disabling SELinux) are worth scruteny by someone SELinux - knowledgable.
In summary, doing as I could do, I can maximally cause a breach in the wall SELinux, but not a security hole, through which the assailant can take over my system.
Now, let's take the opposite stand.
Suppose I limit my changes of SELinux components to packages only. Would I be able to mortally wound the security system of SELInux? In other words could I create a fatal, exploitable flaw in the security system?
Guus.
--
A.J. Bonnema, Leiden The Netherlands,
user #328198 (Linux Counter http://counter.li.org)
