[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: SELinux blocking Gizmo on FC5



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.

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.
----
> 
> Think of implementing an application: no user fully understands the 
> implications of that application, even less are they able to check these 
> implications: they trust the builders. Obviously, this is inherently 
> insecure. (example? One of the anti-virus vendors had parts of a rootkit 
> implemented, creating a possible security hole. The software was 
> generally trusted by users to be secure).
> 
> Now, back to SELInux, I suspect that in general non-admin user can not 
> fully understand what he/she is doing when doing a chcon or changing a 
> policy.
> So, what we need is some sort of high translation of the implications, 
> so that even non-programmer, non-admin users can understand what they 
> are doing on a bit of a higher level than what is currently possible.
> 
> Would it be possible to have a non-technical layer around SELInux so 
> that users can have a more high level view of their security than admins 
> have?
> [Regretfully, many users are admin by default, but not by choice, i.e. 
> home users. They need the high level view...]. Meaning, a user can 
> change the system (high-level) and still know what he/she is doing 
> (high-level).
----
I generally trust the greater minds on this. Consider that if you enable
some rules/policies/contexts, in the worst case scenario, selinux would
still be functional, just not in those particular areas.

Make sure you see the 'selinux for dummies' stuff as that is Daniel
Walsh's attempt to bring the issue of selinux down to a non-technical
level.

Craig


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]