[geeks] geeks Digest, Vol 46, Issue 14

[William Kirkland]

On Sep 14, 2006, at 23:32, geeks-request at sunhelp.org wrote:

> Thu, 14 Sep 2006 @ 16:59 -0500, Michael Parson said:
>
>> On Thu, Sep 14, 2006 at 05:38:40PM -0400, Charles Shannon Hendrix  
>> wrote:
>>> Thu, 14 Sep 2006 @ 00:44 -0700, William Kirkland said:
>>
>> <snip>
>>
>>>> ... and one user will defeat this by installing a private copy of
>>>> some software, that has a specific behavior you have removed, then
>>>> show his buddies ...
>>>
>>> You can stop users from doing this.  If they don't have root,  
>>> they can't
>>> install it in system areas.


>>> If they try to install it in user and data areas they have access  
>>> too,
>>> that's solved by removing the execute option from those paths.

This does not apply, unless you are talking about a captive account.  
I am referring to a typical user account.
Get over it. It should not be the goal of any SA to *control* their  
users.

>>> You really should do that anyway, since there is no reason to be  
>>> able to
>>> execute outside of your application paths anyway.

*IF* this needs to be done, it's time to get a new set of users, or a  
new SA.

>> Users should not have the ability to isntall binaries or scripts in
>> their home directory?
>
> You are changing the subject.

He has asked you to clarify your suggestion. ... would you like to  
change your previous replies ...

> Sun, 10 Sep 2006 @ 11:33 -0700, William Kirkland said:
>> Since the unix world uses flat files to hold the configuration files,
>> you should be able to distribute a script to each node, which would
>> adjust the configuration file of all users. You could even provide it
>> as a wrapper to your browser executable.
>
> The problem here is that a lot of applications modify their
> configuration files constantly.

Users will typically find a way around any type of forced control, as  
will applications (well, their developers). As a system administrator  
you can only define what resources you will allow the user/ 
application/process to use, not how they will make use of them. Limit  
their memory, CPU, i/o ... help them use those resources efficiently,  
restrict their access to other's resources.

My point is that the capability exists in a unix environment (non- 
Micros**t). I am not even suggesting that this method is better than  
what Micros**t has done, to address this issue (the insecurities  
created by Micros**t's implementation are another issue), only that  
the capability exists.


> I wasn't arguing for or against the user execs, I was just pointing  
> out
> you can disable it, because the OP mentioned that was a way of getting
> around sysadmin application policies.

--
Bill.Kirkland at gmail.com