On Dec 5, 2007, at 6:20 PM, Douglas A. Tutty wrote:
I don't know if OpenBSD has any other tricks under the hood to protect
the system from a milicious but legitimate shell user.
They might have a few, I don't know. It's worth noting that their
brag line on their website only refers to *rem
On Wed, Dec 05, 2007 at 04:58:59PM +0100, Martin Marcher wrote:
> On 12/4/07, andy <[EMAIL PROTECTED]> 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
On Dec 5, 2007, at 9:57 AM, Martin Marcher wrote:
But since *nix has a history of being secure because a user/process
can't by default destroy any data besides the data one/it owns. Why
not take that one further and require explicit permission to even run
a program that can potentially destroy d
Martin Marcher wrote:
> Why not take that one further and require explicit permission to even run
> a program that can potentially destroy data?
There are few useful programs without the potential to destroy data.
> Why not take that one further and require explicit permission to run
> _any_ prog
Martin Marcher wrote:
> /usr/bin/perl
> /usr/bin/wget
> /bin/tar
How about /bin/cat, which can be used to transfer copies of any of these
onto the system?
> * Why not take that one further and require explicit permission to run
> _any_ program?
Because then you have a web server with some CGIs.
On 12/5/07, Joey Hess <[EMAIL PROTECTED]> wrote:
> Martin Marcher wrote:
> > So the user needs to get a precompiled gcc somewhere.
> > Then she would need to get all the header files necessary
> > Then she needs to get the source.
> > Then the quota is full... :)
>
> Most systems come with perl. Pe
Martin Marcher wrote:
> So the user needs to get a precompiled gcc somewhere.
> Then she would need to get all the header files necessary
> Then she needs to get the source.
> Then the quota is full... :)
Most systems come with perl. Perl can do anything any non-suid program
in /sbin can do. Most
On 12/5/07, Mike Bird <[EMAIL PROTECTED]> wrote:
> > 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 a
Hi,
On 12/5/07, Nyizsnyik Ferenc <[EMAIL PROTECTED]> wrote:
> On Wed, 5 Dec 2007 16:58:59 +0100
> "Martin Marcher" <[EMAIL PROTECTED]> wrote:
> > /bin root:users rwxr-x---
> > /sbin root:adm rwxr-x---
> > /usr/bin root:users rwxr-x---
> > /usr/sbin root:adm rwxr-x---
>
> I do get your idea, but ha
On Wednesday 05 December 2007 07:58:59 Martin Marcher wrote:
> On 12/4/07, andy <[EMAIL PROTECTED]> 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
On Wed, 5 Dec 2007 16:58:59 +0100
"Martin Marcher" <[EMAIL PROTECTED]> wrote:
> Hi,
>
> jumping in.
>
> On 12/4/07, andy <[EMAIL PROTECTED]> 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 defau
Hi,
jumping in.
On 12/4/07, andy <[EMAIL PROTECTED]> 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
12 matches
Mail list logo
