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
11 matches
Mail list logo
