Re: permissions in general (WAS: Re: permissions in /sbin)
On Wed, Dec 05, 2007 at 04:58:59PM +0100, Martin Marcher wrote:
> On 12/4/07, andy <geek_show@dsl.pipex.com> wrote:
> > ls -l /sbin is all
> >
> > -rwxr-xr-x 1 root root ...
>
> I understand this issue. What I don't get is why it seems to be the
> overall default that others may read and execute files in most cases.
>
> To me it would make sense to have something like (very naive right
> now, hope you get the idea):
>
> /bin root:users rwxr-x---
> /sbin root:adm rwxr-x---
> /usr/bin root:users rwxr-x---
> /usr/sbin root:adm rwxr-x---
>
> and so on. Using acl's it would be very easy to add even more groups.
> I think the explicit adding of others would make a lot of sense and
> secure the system in a standard way.
>
> I guess it's more a historical reason that others can r+x most of the
> system but I can see a lot of benefits in denying others by default
> (of course there's a lot of work involved to migrate from the current
> permission schema that's at least a serious drawback)
>
> What do you think?
You'll get all the rationale for the unix way of doing things. However,
in all Unix contexts, the highest threat is from someone with shell
access. An attacker ultimatly wants root. Usually the best way to get
that is to get a regular user access first. So the first rule is to
only give user access to people you trust (or people you can dicipline).
The difficulty is most acute with public access "kiosk" systems. Review
the archives for discussions on all the hoops through which admins must
jump to provide any hope of security.
Thus, its safe to say, that for any unix, there must be some trust of
shell users or security is breached. Chroots and VM's on i386/amd64
hardware aren't an answer either. The only alternative in unix is to
give user's a custom app from which they can't escape which will only do
what you want them to do.
I don't know if OpenBSD has any other tricks under the hood to protect
the system from a milicious but legitimate shell user.
The only other option is to get out of unix and go to something like
OS/400 or OpenVMS. I'm shaky on the details of those systems, but I
think you create task groups, add users and file-like thingies and
applications and it keeps them separate from other task groups. Much of
the support for this seperation is at the hardware level (AS/400,
mainframe, etc) and can't be done on normal unix boxes.
Doug.
Reply to: