[NTLUG:Discuss] Last meeting, you CAN have hotplugged devices automount without desktop

Chris Cox cjcox at acm.org
Sat Jan 26 20:29:51 CST 2008


Leroy Tennison wrote:
> Chris Cox wrote:
>> Ted Gould wrote:
>>> On Thu, 2008-01-24 at 23:18 -0600, Chris Cox wrote:
>>>> Robert Pearson wrote:
>>>>> How would you control access to these devices to include some users
>>>>> and exclude others?
>>>> Well... my guess is that perhaps PolicyKit would allow one to
>>>> define devices for access differently between users.  Not exactly
>>>> the panacea everything to everyone idea... more like this user
>>>> can do these kinds of things with these kinds of devices.
>>> Yes, it should.  But considering PolicyKit isn't really out in the wild,
>>> and you're commenting on how it is done today (while mentioning that the
>>> *Kits are useless) they don't really gel.  Yes, PolicyKit will help to
>>> fix this issue, but that's the future.  Today we don't have a security
>>> framework that can deal with that complexity.
>>>
>>>>> Perhaps there is a simple Security design. Sometimes I complicate things.
>>>>> The "Rule of Thumb" in the past was "Better Safe Than Sorry" so access
>>>>> was very restrictive for private Information in public places.
>>>> Complicated security implementations usually end up dying.  Just
>>>> my own observation.
>>> Are you saying that PolicyKit will die?  AppArmor?  SELinux?
>> AppArmor is simple... but may die just because.  SELinux... sheesh...
>> must die.  We'll have to see how PolicyKit comes out.  I may be
>> very useful.  Or it could be the UCE of Linux, not enough
>> benefit to be useful (especially if painful to configure or if
>> it doesn't make sense).
>>
>> _______________________________________________
>> http://www.ntlug.org/mailman/listinfo/discuss
>>
> The problem with complicated security solutions (regardless of specific 
> instance, actually "complicated anything") is that they are: 
> complicated.  This has disadvantages which drive people away -
> 
> They are intimidating to the new would-be user so adoption is stifled.
> 
> Even if a "guru" masters the technology, what about the poor soul(s) who 
> are left to maintain it after the guru inevitably leaves the 
> organization.  Then there's the fear of blackmail/extortion/etc. (the 
> guru holds the keys and decides to become an adversary while still 
> employed).  Finally, people like that can usually command a higher 
> salary than those who don't apply themselves and thus have to accept 
> lower pay.  Management hates those kind of people because they are an 
> obstacle to cutting labor costs and maximizing management's compensation 
> (never mind all the "you get what you pay for" arguments - such thoughts 
> seem far too lofty for most management mentality though there are 
> exceptions).
> 
> They tend to produce solutions which are hard to verify.  Because of the 
> complexity you're never really sure there isn't one or more holes 
> lurking in the maze.

As an example, with SELinux, the first thing almost every enterprise
piece of software has you do to run is to shut it down.

The reason, there's no easy way to predict the SELinux policy that is
in place and there's no easy way to explain what is needed (because
the policy could be vastly different) to make things work with
SELinux.



More information about the Discuss mailing list