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
