Mike Belopuhov | 16 Oct 22:18 2004
Picon

sudo: why not?

Hi.

I'm just skipping some gratitudes to Owl team ;-) and just asking
a question: why sudo is not in Owl?  Always when I install Owl I
can't guess why it is so.  It works fine with tcb.

I have working srpm of sudo with .pam and .control files included
(tested on 1.1-release on i386).  It's sudo-1.6.7p5.  You can get
SRPM here:
     http://openbsd.hnet.spb.ru/files/sudo-1.6.7p5-owl1.src.rpm

(sorry if it happens to be broken ;-)

Suppose there is much to be done, but imho sudo is a good candidate
for the owl-current, isn't it?

PS.
Of course I googled for a such discussion, but hasn't found
anything relevant.

--

-- 
 Mike Belopuhov
 * ТХИС МЕССАГЕ ВАС ВРИТТЕН УСИНГ ЖИМ *

misiu_ | 20 Oct 18:29 2004
Picon
Picon

installed and chrooted and now?

Hello list,

this is my first contact with Owl. Now I installed the system as in the
install-doc than I issued a chroot /owl
and no? how do I set up the kernel? install lilo? 
do you have any documentation?

thanx,
misiu
gremlin | 20 Oct 18:48 2004
Picon

Re: installed and chrooted and now?

misiu_ wrote:

> this is my first contact with Owl. Now I installed the system as in the
> install-doc than I issued a chroot /owl
> and no? how do I set up the kernel? install lilo?
> do you have any documentation?

Simplest way:
1. Copy kernel from CD
# cp /boot/bzImage /owl/boot/
2. Setup LILO
# make setup
# vi /owl/etc/lilo.conf
3. Install LILO
# chroot /owl lilo

Then boot up from hard disk and build custom kernel usual way.

--

-- 
Alexey V. Vissarionov aka Gremlin from Kremlin

misiu_ | 20 Oct 19:02 2004
Picon
Picon

Re: installed and chrooted and now?

Am Mi, den 20.10.2004 schrieb gremlin um 18:48:

> Simplest way:
> 1. Copy kernel from CD
> # cp /boot/bzImage /owl/boot/
o.k.
> 2. Setup LILO
> # make setup
> # vi /owl/etc/lilo.conf
after /sbin/lilo
i get 
Warning: LBA32 addressing assumed
lilo: fatal: geo_query_dev HDIO_GETGEO(dev 0x1600):Invalid argument

any suggestions?

misiu
> 3. Install LILO
> # chroot /owl lilo
> 
> Then boot up from hard disk and build custom kernel usual way.
> 
gremlin | 20 Oct 19:13 2004
Picon

Re: installed and chrooted and now?

misiu_ wrote:

> > 1. Copy kernel from CD
> > # cp /boot/bzImage /owl/boot/
> o.k.
> > 2. Setup LILO
> > # make setup
> > # vi /owl/etc/lilo.conf
> after /sbin/lilo
> i get
> Warning: LBA32 addressing assumed
> lilo: fatal: geo_query_dev HDIO_GETGEO(dev 0x1600):Invalid argument
> 
> any suggestions?

Hmm... AFAIR, 0x1600 is a sort of SCSI disk - possibly, you have to edit
/owl/etc/lilo.conf to suit your needs.

> > 3. Install LILO
> > # chroot /owl lilo

--

-- 
Alexey V. Vissarionov aka Gremlin from Kremlin

gremlin | 20 Oct 19:20 2004
Picon

Re: installed and chrooted and now?


> > after /sbin/lilo
> > i get
> > Warning: LBA32 addressing assumed
> > lilo: fatal: geo_query_dev HDIO_GETGEO(dev 0x1600):Invalid argument
> >
> > any suggestions?
> 
> Hmm... AFAIR, 0x1600 is a sort of SCSI disk - possibly, you have to edit
> /owl/etc/lilo.conf to suit your needs.
> 
> > > 3. Install LILO
> > > # chroot /owl lilo

[I'll never post drunk messages to list! I'll never post dru...]

0x1600 is /dev/hdc (22,0) - is that your hard disk device, or is it a
CD-ROM?

--

-- 
Alexey V. Vissarionov aka Gremlin from Kremlin

Solar Designer | 20 Oct 21:55 2004

Re: sudo: why not?

Hi Mike,

On Sun, Oct 17, 2004 at 12:18:02AM +0400, Mike Belopuhov wrote:
> I'm just skipping some gratitudes to Owl team ;-) and just asking
> a question: why sudo is not in Owl?  Always when I install Owl I
> can't guess why it is so.  It works fine with tcb.

Yes, but unfortunately both su and sudo are subtly but fundamentally
flawed.

Presently, the only safe use for su is to switch from a more
privileged account to a less privileged one (whenever this distinction
can be made) in a non-interactive script (without a tty).  As soon as
a tty is used, there is a security problem.  As soon as you su to a
more privileged account, there is another security problem.

We've been discussing privately how we might re-design su (or
improve Linux kernel interfaces) such that su would become safe in
presence of tty's.  However, even if that is done, su would still be
unsafe for accessing more privileged accounts from less privileged
ones.

Yes, it used to be common sysadmin wisdom to "su root" rather than
login as root.  Those few who, when asked, could actually come up with
a valid reason for this preference would refer to the better
accountability achieved with this approach.  Yes, this really is a
good reason in favor of this approach.  But it's also the only one.
And the reason I give against using this approach is that it
effectively allows anyone who could have compromised the otherwise
non-privileged user account used to su from to gain root (at the
(Continue reading)

Steven Lembark | 20 Oct 22:36 2004

Re: sudo: why not?


> Presently, the only safe use for su is to switch from a more
> privileged account to a less privileged one (whenever this distinction
> can be made) in a non-interactive script (without a tty).  As soon as
> a tty is used, there is a security problem.  As soon as you su to a
> more privileged account, there is another security problem.

Catch: priv'd accounts can depend on context. What may be
less priv'd in one context (say, dba access vs. reformat the
disks) can be more priv'd in another (say, modify someone's
payroll record).

> Yes, it used to be common sysadmin wisdom to "su root" rather than
> login as root.  Those few who, when asked, could actually come up with
> a valid reason for this preference would refer to the better
> accountability achieved with this approach.  Yes, this really is a
> good reason in favor of this approach.  But it's also the only one.

You can also refuse superuser logins over the network (from
the root username or any other with UID 0). At that point
someone has to compromise the system enough to modify the
login rules before they can get in as root via the network.

You can restrict the number of users with simple access to
the command via mods, which allows revoking access to the
command by removing a user from one group (vs. having to
change the password). While not perfect, this does simplify
the most common cases where ex-employees have su access
because Jow Bloe in accouting couldn't be notified of the
change.
(Continue reading)

misiu_ | 20 Oct 23:59 2004
Picon
Picon

Re: installed and chrooted and now?

hi, i guess it is my cdrom...
but in my lilo.conf
is  
"boot=/dev/hda1"
"root=/dev/hda"

misiu

Am Mi, den 20.10.2004 schrieb gremlin um 19:20:
> > > after /sbin/lilo
> > > i get
> > > Warning: LBA32 addressing assumed
> > > lilo: fatal: geo_query_dev HDIO_GETGEO(dev 0x1600):Invalid argument
> > >
> > > any suggestions?
> > 
> > Hmm... AFAIR, 0x1600 is a sort of SCSI disk - possibly, you have to edit
> > /owl/etc/lilo.conf to suit your needs.
> > 
> > > > 3. Install LILO
> > > > # chroot /owl lilo
> 
> [I'll never post drunk messages to list! I'll never post dru...]
> 
> 0x1600 is /dev/hdc (22,0) - is that your hard disk device, or is it a
> CD-ROM?
Andreas Ericsson | 21 Oct 00:06 2004
Picon

Re: sudo: why not?

Steven Lembark wrote:
> 
>> Presently, the only safe use for su is to switch from a more
>> privileged account to a less privileged one (whenever this distinction
>> can be made) in a non-interactive script (without a tty).  As soon as
>> a tty is used, there is a security problem.  As soon as you su to a
>> more privileged account, there is another security problem.
> 
> 
> Catch: priv'd accounts can depend on context. What may be
> less priv'd in one context (say, dba access vs. reformat the
> disks) can be more priv'd in another (say, modify someone's
> payroll record).
> 

The root user could access the database files physically 
(binaryphorically speaking) and thus already has this privilege. There 
is really no such thing as security against the superuser.

>> Yes, it used to be common sysadmin wisdom to "su root" rather than
>> login as root.  Those few who, when asked, could actually come up with
>> a valid reason for this preference would refer to the better
>> accountability achieved with this approach.  Yes, this really is a
>> good reason in favor of this approach.  But it's also the only one.
> 
> 
> You can also refuse superuser logins over the network (from
> the root username or any other with UID 0). At that point
> someone has to compromise the system enough to modify the
> login rules before they can get in as root via the network.
(Continue reading)


Gmane