"DadOS" - sys shutdown with XDM

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

"DadOS" - sys shutdown with XDM

J.C. Roberts-2
My dad (68 years old) has finally succeeded in destroying/infecteding
his MS-Windows NT4 box, in spite of my best efforts to secure the darn
thing (e.g. No MSIE, No "Microsoft Networking", stripped of just about
everything MS-ish and with tons of hand made patches, behind an openbsd
firewall... and so on and so forth). It lasted a good four years in the
hands of a typical user that hates computers, clicks on everything and
still expects everything to "just work" and work properly.

Since I'm the person somehow responsible for keeping all system in my
family running and I'm not willing to fix MS problems anymore, Dad will
be running OpenBSD from here on out... -He doesn't like the idea and is
resistant to change or learning new things.

I haven't used KDE since circa OpenBSD 2.9 but he wanted the system to
look familiar, so I installed KDE and configured it to look like NT/2K.

He wanted a "simple" login (read: "graphical"), so I set up XDM and soft
linked his ~/.xsession to /usr/local/bin/startkde to get KDE going on
login of his user account.

Dad thought the idea of needing to enter a password and remember an
esoteric sudo command to shut down the system was just insane, so he
wanted the KDE "Log Out" menu item to just shut the system down for him.

This is where things get interesting... I know you can have a "shutdown"
option in KDM but I don't want to run kdm mainly because the graphics on
the OpenBSD XDM are much cooler. ;) -Actually, my reasoning is that xdm
has been audited and has been wired into OpenBSD properly while kdm is
an unknown, a port and I simply don't want to mess with it.

  # echo "xdm_flags=\"\"" >>/etc/rc.conf.local

The first thing I did was add a "flag file" to my dad's home directory
and made sure he cant modify or delete it.

  # touch /home/dad/.xshutdown
  # chown root:wheel /home/dad/.xshutdown
  # chmod 400 /home/dad/.xshutdown

Since /etc/X11/xdm/TakeConsole runs with root permission on every user
logout to prevent /dev/console sniffing I modified it to perform the
shutdown if the flag file is found in the users home directory.

  # cat /etc/X11/xdm/TakeConsole
  #!/bin/sh
  # Reassign ownership of the console to root, this should disallow
  # assignment of console output to any random users's xterm
  # $Xorg: TakeConsole,v 1.3 2000/08/17 19:54:17 cpqbld Exp $
  # $OpenBSD: TakeConsole,v 1.3 2004/11/03 00:22:21 matthieu Exp $
  #
  chmod 622 /dev/console
  chown root /dev/console
  /usr/X11R6/bin/sessreg -d -l $DISPLAY -u /var/run/utmp \
    -x /usr/X11R6/lib/X11/xdm/Xservers $USER
 
  if [ -f "$HOME/.xshutdown" ]; then
          shutdown -hp now
  fi
  #
 
This approach works perfectly but my questions are:
  Is there anything wrong with this approach?
  Is there's a better way to deal with the problem?

I know it's a "holy war" topic, but do you have a recommendation for an
email client he could use?

thanks,
jcr

Reply | Threaded
Open this post in threaded view
|

Re: "DadOS" - sys shutdown with XDM

Hannah Schroeter
Hello!

On Tue, Jan 03, 2006 at 03:24:22AM -0800, J.C. Roberts wrote:
>My dad (68 years old) has finally succeeded in destroying/infecteding
>his MS-Windows NT4 box, in spite of my best efforts to secure the darn
>thing (e.g. No MSIE, No "Microsoft Networking", stripped of just about
>everything MS-ish and with tons of hand made patches, behind an openbsd
>firewall... and so on and so forth). It lasted a good four years in the
>hands of a typical user that hates computers, clicks on everything and
>still expects everything to "just work" and work properly.

4 years w/o infection isn't that bad for windoze... :-)

>[...]

>The first thing I did was add a "flag file" to my dad's home directory
>and made sure he cant modify or delete it.

>  # touch /home/dad/.xshutdown
>  # chown root:wheel /home/dad/.xshutdown
>  # chmod 400 /home/dad/.xshutdown

>Since /etc/X11/xdm/TakeConsole runs with root permission on every user
>logout to prevent /dev/console sniffing I modified it to perform the
>shutdown if the flag file is found in the users home directory.

>  # cat /etc/X11/xdm/TakeConsole
>  #!/bin/sh
>  # Reassign ownership of the console to root, this should disallow
>  # assignment of console output to any random users's xterm
>  # $Xorg: TakeConsole,v 1.3 2000/08/17 19:54:17 cpqbld Exp $
>  # $OpenBSD: TakeConsole,v 1.3 2004/11/03 00:22:21 matthieu Exp $
>  #
>  chmod 622 /dev/console
>  chown root /dev/console
>  /usr/X11R6/bin/sessreg -d -l $DISPLAY -u /var/run/utmp \
>    -x /usr/X11R6/lib/X11/xdm/Xservers $USER
>  
>  if [ -f "$HOME/.xshutdown" ]; then
>          shutdown -hp now
>  fi
>  #

>This approach works perfectly but my questions are:
>  Is there anything wrong with this approach?
>  Is there's a better way to deal with the problem?

I know no better way offhand. It looks hacky, but it'll keep
working I guess.

>I know it's a "holy war" topic, but do you have a recommendation for an
>email client he could use?

kmail is quite usable and it'll be the mail client best integrated
into the rest of your dad's desktop, if he's gonna use the OpenBSD/KDE
box.

>thanks,
>jcr

Kind regards,

Hannah.

Reply | Threaded
Open this post in threaded view
|

Re: "DadOS" - sys shutdown with XDM

Joachim Schipper
In reply to this post by J.C. Roberts-2
On Tue, Jan 03, 2006 at 03:24:22AM -0800, J.C. Roberts wrote:
> My dad (68 years old) has finally succeeded in destroying/infecteding
> his MS-Windows NT4 box, in spite of my best efforts to secure the darn
> thing (e.g. No MSIE, No "Microsoft Networking", stripped of just about
> everything MS-ish and with tons of hand made patches, behind an openbsd
> firewall... and so on and so forth). It lasted a good four years in the
> hands of a typical user that hates computers, clicks on everything and
> still expects everything to "just work" and work properly.

Not half bad!

> Dad thought the idea of needing to enter a password and remember an
> esoteric sudo command to shut down the system was just insane, so he
> wanted the KDE "Log Out" menu item to just shut the system down for him.
>
> This is where things get interesting... I know you can have a "shutdown"
> option in KDM but I don't want to run kdm mainly because the graphics on
> the OpenBSD XDM are much cooler. ;) -Actually, my reasoning is that xdm
> has been audited and has been wired into OpenBSD properly while kdm is
> an unknown, a port and I simply don't want to mess with it.
>
>   # echo "xdm_flags=\"\"" >>/etc/rc.conf.local
>
> The first thing I did was add a "flag file" to my dad's home directory
> and made sure he cant modify or delete it.
>
>   # touch /home/dad/.xshutdown
>   # chown root:wheel /home/dad/.xshutdown
>   # chmod 400 /home/dad/.xshutdown
>
> Since /etc/X11/xdm/TakeConsole runs with root permission on every user
> logout to prevent /dev/console sniffing I modified it to perform the
> shutdown if the flag file is found in the users home directory.
>
>   # cat /etc/X11/xdm/TakeConsole
>   #!/bin/sh
>   # Reassign ownership of the console to root, this should disallow
>   # assignment of console output to any random users's xterm
>   # $Xorg: TakeConsole,v 1.3 2000/08/17 19:54:17 cpqbld Exp $
>   # $OpenBSD: TakeConsole,v 1.3 2004/11/03 00:22:21 matthieu Exp $
>   #
>   chmod 622 /dev/console
>   chown root /dev/console
>   /usr/X11R6/bin/sessreg -d -l $DISPLAY -u /var/run/utmp \
>     -x /usr/X11R6/lib/X11/xdm/Xservers $USER
>  
>   if [ -f "$HOME/.xshutdown" ]; then
>           shutdown -hp now
>   fi
>   #
>  
> This approach works perfectly but my questions are:
>   Is there anything wrong with this approach?
>   Is there's a better way to deal with the problem?

This is a hack. It will work, untill you upgrade X11 without being very
careful.

Why not just configure sudo to allow access to /sbin/halt without a
password from user dad? Of course, you then alter the KDE menu to do it
your way. And/or place a two-line shell script in ~dad/bin/halt:

#!/bin/sh
sudo /sbin/halt

> I know it's a "holy war" topic, but do you have a recommendation for an
> email client he could use?

Hannah's point on KMail is good. I don't know what he used previously,
but if that one is available for *nix, use it. If not, something
similar.

Basically, all mail clients suck. And the one that sucks less is not
very newbie-friendly.

                Joachim

Reply | Threaded
Open this post in threaded view
|

Re: "DadOS" - sys shutdown with XDM

terry tyson
On Tue, 3 Jan 2006, Joachim Schipper wrote:

> Basically, all mail clients suck. And the one that sucks less is not
> very newbie-friendly.
>
> Joachim
Hehehe, I agree. However, I have used a few graphical clients that
weren't too bad. Evolution, Thunderbird, and Sylpheed-Claws. A few
weeks ago I tried to load Evolution on a box but had problems. Never
had problems with the other two. Thunderbird is probably a little more
user friendly than Sylpheed-Claws tho.

--
Terry

Reply | Threaded
Open this post in threaded view
|

Re: "DadOS" - sys shutdown with XDM

Michael Erdely
In reply to this post by Joachim Schipper
On 1/3/06, Joachim Schipper <[hidden email]> wrote:

> > Since /etc/X11/xdm/TakeConsole runs with root permission on every user
> > logout to prevent /dev/console sniffing I modified it to perform the
> > shutdown if the flag file is found in the users home directory.
> >
> >   # cat /etc/X11/xdm/TakeConsole
> >   #!/bin/sh
> >   # Reassign ownership of the console to root, this should disallow
> >   # assignment of console output to any random users's xterm
> >   # $Xorg: TakeConsole,v 1.3 2000/08/17 19:54:17 cpqbld Exp $
> >   # $OpenBSD: TakeConsole,v 1.3 2004/11/03 00:22:21 matthieu Exp $
> >   #
> >   chmod 622 /dev/console
> >   chown root /dev/console
> >   /usr/X11R6/bin/sessreg -d -l $DISPLAY -u /var/run/utmp \
> >     -x /usr/X11R6/lib/X11/xdm/Xservers $USER
> >
> >   if [ -f "$HOME/.xshutdown" ]; then
> >           shutdown -hp now
> >   fi
> >   #
> >
> > This approach works perfectly but my questions are:
> >   Is there anything wrong with this approach?
> >   Is there's a better way to deal with the problem?
>
> This is a hack. It will work, untill you upgrade X11 without being very
> careful.
>
> Why not just configure sudo to allow access to /sbin/halt without a
> password from user dad? Of course, you then alter the KDE menu to do it
> your way. And/or place a two-line shell script in ~dad/bin/halt:
>
Add dad to the operator group which can run /sbin/shutdown without  sudo.

--
http://erdelynet.com/
Support OpenBSD! http://www.openbsd.org/orders.html

Reply | Threaded
Open this post in threaded view
|

Re: "DadOS" - sys shutdown with XDM

Joachim Schipper
On Tue, Jan 03, 2006 at 12:45:46PM -0500, Michael Erdely wrote:
> On 1/3/06, Joachim Schipper <[hidden email]> wrote:
> > > Since /etc/X11/xdm/TakeConsole runs with root permission on every user
> > > logout to prevent /dev/console sniffing I modified it to perform the
> > > shutdown if the flag file is found in the users home directory.

> > > This approach works perfectly but my questions are:
> > >   Is there anything wrong with this approach?
> > >   Is there's a better way to deal with the problem?
> >
> > This is a hack. It will work, untill you upgrade X11 without being very
> > careful.
> >
> > Why not just configure sudo to allow access to /sbin/halt without a
> > password from user dad? Of course, you then alter the KDE menu to do it
> > your way. And/or place a two-line shell script in ~dad/bin/halt:
> >
> Add dad to the operator group which can run /sbin/shutdown without  sudo.

That's not a very good idea.

$ ls -la /dev/wd*
brw-r-----  1 root  operator    0,   0 Nov  2 18:20 /dev/wd0a
brw-r-----  1 root  operator    0,   1 Nov  2 18:20 /dev/wd0b
brw-r-----  1 root  operator    0,   2 Nov  2 18:20 /dev/wd0c
<more>
brw-r-----  1 root  operator    0,  15 Nov  2 18:20 /dev/wd0p
brw-r-----  1 root  operator    0,  16 Nov  2 18:19 /dev/wd1a
<and so on>

And operator has more priviliges; more than enough to trash the system,
if he wants to, or to get root, if he is somewhat skilled. Far better to
just change a single line in /etc/sudoers.

                Joachim

Reply | Threaded
Open this post in threaded view
|

Re: "DadOS" - sys shutdown with XDM

Juha Erkkila
On Tue, Jan 03, 2006 at 07:04:36PM +0100, Joachim Schipper wrote:

> On Tue, Jan 03, 2006 at 12:45:46PM -0500, Michael Erdely wrote:
> > Add dad to the operator group which can run /sbin/shutdown without  sudo.
>
> That's not a very good idea.
>
> $ ls -la /dev/wd*
> brw-r-----  1 root  operator    0,   0 Nov  2 18:20 /dev/wd0a
> brw-r-----  1 root  operator    0,   1 Nov  2 18:20 /dev/wd0b
> brw-r-----  1 root  operator    0,   2 Nov  2 18:20 /dev/wd0c
> <more>
> brw-r-----  1 root  operator    0,  15 Nov  2 18:20 /dev/wd0p
> brw-r-----  1 root  operator    0,  16 Nov  2 18:19 /dev/wd1a
> <and so on>
>
> And operator has more priviliges; more than enough to trash the system,
> if he wants to, or to get root, if he is somewhat skilled. Far better to
> just change a single line in /etc/sudoers.

while i don't disagree with your advice, could you still advice me
on messing things up with operator privileges, as i'm curious...
because i can't see how being able to read disks will give out
enough information to do either

Juha

Reply | Threaded
Open this post in threaded view
|

Re: "DadOS" - sys shutdown with XDM

patrick ~
In reply to this post by J.C. Roberts-2
> The first thing I did was add a "flag file" to my dad's home directory
> and made sure he cant modify or delete it.
>
>   # touch /home/dad/.xshutdown
>   # chown root:wheel /home/dad/.xshutdown
>   # chmod 400 /home/dad/.xshutdown


login: dad
password: ********
dadsbox $ ls -l .xshutdown
-r--------    1 root     wheel           0 Jan  3 11:11 .xshutdown
dadsbox $ mv .xshutdown /tmp
dadsbox $ echo ":-)"
:-)



Assuming, of course, that /tmp and /home are
one partition.

--patrick

Reply | Threaded
Open this post in threaded view
|

Re: "DadOS" - sys shutdown with XDM

Joachim Schipper
In reply to this post by Juha Erkkila
On Tue, Jan 03, 2006 at 08:24:44PM +0200, Juha Erkkila wrote:

> On Tue, Jan 03, 2006 at 07:04:36PM +0100, Joachim Schipper wrote:
> > On Tue, Jan 03, 2006 at 12:45:46PM -0500, Michael Erdely wrote:
> > > Add dad to the operator group which can run /sbin/shutdown without  sudo.
> >
> > That's not a very good idea.
> >
> > $ ls -la /dev/wd*
> > brw-r-----  1 root  operator    0,   0 Nov  2 18:20 /dev/wd0a
> > brw-r-----  1 root  operator    0,   1 Nov  2 18:20 /dev/wd0b
> > brw-r-----  1 root  operator    0,   2 Nov  2 18:20 /dev/wd0c
> > <more>
> > brw-r-----  1 root  operator    0,  15 Nov  2 18:20 /dev/wd0p
> > brw-r-----  1 root  operator    0,  16 Nov  2 18:19 /dev/wd1a
> > <and so on>
> >
> > And operator has more priviliges; more than enough to trash the system,
> > if he wants to, or to get root, if he is somewhat skilled. Far better to
> > just change a single line in /etc/sudoers.
>
> while i don't disagree with your advice, could you still advice me
> on messing things up with operator privileges, as i'm curious...
> because i can't see how being able to read disks will give out
> enough information to do either

Hmm, I must admit that the group operator has less priviliges than I'd
have expected. Sorry, I really should check my suspicions.

The most absolute is a nasty DoS called /sbin/halt, but since that was
the intention we'll let that slip.
There are also less obvious ways to DoS a machine, but since we can
already shut it down there's no reason to annoy people a little - after
all, you can annoy them a lot. And I don't see any obvious way to get
the operator group to help with that.

The second most nasty attack is getting /etc/master.passwd and running a
cracking tool on it - this will yield any weak passwords easily. This is
rather obvious, but if using weak passwords can be very dangerous.
/etc/master.passwd uses rather strong encryption, but other password
files are typically easier to crack. This would be rather annoying on
a shared machine, but since this is a single-user system there's usually
little extra access to be gained.

If the system uses backup tapes, the user operator can overwrite them.
This can be quite disastrous, but I'm fairly certain this isn't much of
a problem in this case.

And that's about it. The group operator can read all files on the
system, which would be rather nasty in a multi-user setup where the
documents are confidential or at least private, but since that's not the
case I don't see too much of a problem.

Sorry!

                Joachim

Reply | Threaded
Open this post in threaded view
|

Re: "DadOS" - sys shutdown with XDM

Hannah Schroeter
In reply to this post by patrick ~
Hello!

On Tue, Jan 03, 2006 at 11:15:46AM -0800, patrick ~ wrote:
>> The first thing I did was add a "flag file" to my dad's home directory
>> and made sure he cant modify or delete it.

>>   # touch /home/dad/.xshutdown
>>   # chown root:wheel /home/dad/.xshutdown
>>   # chmod 400 /home/dad/.xshutdown

>login: dad
>password: ********
>dadsbox $ ls -l .xshutdown
>-r--------    1 root     wheel           0 Jan  3 11:11 .xshutdown
>dadsbox $ mv .xshutdown /tmp
>dadsbox $ echo ":-)"
>:-)

>Assuming, of course, that /tmp and /home are
>one partition.

If not, mv .xshutdown .xnoshutdown is enough too.

But then, chflags schg .xshutdown may be enough.

>--patrick

Kind regards,

Hannah.

Reply | Threaded
Open this post in threaded view
|

Re: "DadOS" - sys shutdown with XDM

J.C. Roberts-2
In reply to this post by Juha Erkkila
On Tue, 3 Jan 2006 20:24:44 +0200, Juha Erkkila <[hidden email]>
wrote:

>On Tue, Jan 03, 2006 at 07:04:36PM +0100, Joachim Schipper wrote:
>> On Tue, Jan 03, 2006 at 12:45:46PM -0500, Michael Erdely wrote:
>> > Add dad to the operator group which can run /sbin/shutdown without  sudo.
>>
>> That's not a very good idea.
>>
>> $ ls -la /dev/wd*
>> brw-r-----  1 root  operator    0,   0 Nov  2 18:20 /dev/wd0a
>> brw-r-----  1 root  operator    0,   1 Nov  2 18:20 /dev/wd0b
>> brw-r-----  1 root  operator    0,   2 Nov  2 18:20 /dev/wd0c
>> <more>
>> brw-r-----  1 root  operator    0,  15 Nov  2 18:20 /dev/wd0p
>> brw-r-----  1 root  operator    0,  16 Nov  2 18:19 /dev/wd1a
>> <and so on>
>>
>> And operator has more priviliges; more than enough to trash the system,
>> if he wants to, or to get root, if he is somewhat skilled. Far better to
>> just change a single line in /etc/sudoers.
>
>while i don't disagree with your advice, could you still advice me
>on messing things up with operator privileges, as i'm curious...
>because i can't see how being able to read disks will give out
>enough information to do either
>
>Juha

The ability to read any file on the system is a *clear* violation of the
"Principle of Least Privilege."

Let's say, for the sake of argument, that the user account is some how
compromised; Do you really want the attacker to be able to read every
file on the system?  -Obviously, letting a user account read everything
makes it easier for the attacker to escalate their privileges.

The rule of thumb for granting privileges is simple; avoid granting
permissions whenever possible.

jcr

Reply | Threaded
Open this post in threaded view
|

Re: "DadOS" - sys shutdown with XDM

dfeustel
On Tuesday 03 January 2006 17:11, J.C. Roberts wrote:

> The rule of thumb for granting privileges is simple; avoid granting
> permissions whenever possible.

Check the ownership/privileges on /tmp/.X11-unix/X0 after you start kde or Xorg.

Also check the ownership/privileges on the /dev/[pt]typ* pair allocated
to any konsole session running under kde on openbsd.

--
Lose, v., experience a loss, get rid of, "lose the weight"
Loose, adj., not tight, let go, free, "loose clothing"

Reply | Threaded
Open this post in threaded view
|

Re: "DadOS" - sys shutdown with XDM

J.C. Roberts-2
In reply to this post by Hannah Schroeter
On Tue, 3 Jan 2006 15:03:31 +0100, Hannah Schroeter <[hidden email]>
wrote:

>On Tue, Jan 03, 2006 at 03:24:22AM -0800, J.C. Roberts wrote:
>>My dad (68 years old) has finally succeeded in destroying/infecteding
>>his MS-Windows NT4 box, in spite of my best efforts to secure the darn
>>thing (e.g. No MSIE, No "Microsoft Networking", stripped of just about
>>everything MS-ish and with tons of hand made patches, behind an openbsd
>>firewall... and so on and so forth). It lasted a good four years in the
>>hands of a typical user that hates computers, clicks on everything and
>>still expects everything to "just work" and work properly.
>
>4 years w/o infection isn't that bad for windoze... :-)

Most people would be amazed what is actually possible with Win32. My
current record is six+ years but calling the result of my efforts
"Microsoft Windows" is a bit of a stretch:

root@mercury ~
$ ls -lF /
ls: /pagefile.sys: No such file or directory
total 784
-r-xr-xr-x    1 Administ None            0 Jul  5  2003 IO.SYS*
-r-xr-xr-x    1 Administ None            0 Jul  5  2003 MSDOS.SYS*
-rwxrwxrwx    1 Administ None        34468 Dec  7  1999 NTDETECT.COM*
-rwxrwxrwx    1 Administ None       214416 Dec  7  1999 NTLDR*
drwxrwxrwx+   3 Administ None            0 Aug 18  2003 RECYCLER/
drwxrwxrwx+  15 Administ None        12288 Oct 26 13:12 _media_/
drwxrwxrwx+   3 Administ None            0 Sep  7 12:10 _test/
-rwxrwxrwx    1 Administ None         6808 Oct 28 02:10 _viminfo*
drwxrwxrwx+ 104 Administ None        28672 Nov 26 01:36 app/
drwxrwxrwx+ 177 Administ None        81920 Dec 31 02:50 arc/
drwxrwxrwx+   4 Administ None         4096 Jun 23  2004 bcd/
drwxrwxrwx+   3 Administ None       303104 Aug 18 05:58 bin/
-r-xr-xr-x    1 Administ None          286 Jul  5  2003 boot.ini*
-rwxrwxrwx    1 Administ None         8192 Jul  2  2003 bootsec.bin*
-rwxrwxrwx    1 Administ None         8192 Aug 15  2003 bootsec2.bin*
drwxrwxrwx+   2 Administ None            0 Nov 26 02:07 cad/
-rwxrwxrwx    1 Administ None           51 Aug 18 05:52 cygwin.bat*
-rwxrwxrwx    1 Administ None          766 Jul 12  2003 cygwin.ico*
drwxrwxrwx+  21 Administ None        24576 Sep 28 06:23 etc/
drwxrwxrwx+   8 Administ None         4096 Apr 20  2004 home/
drwxrwxrwx+  28 Administ None        77824 Aug 15  2003 lib/
-rwxrwxrwx    1 Administ None        24576 Jan  7  2003 mkbt.exe*
-rwxrwxrwx    1 Administ None       368756 Jun  2  2004 mkbt.idb*
drwxrwxrwx+   2 Administ None         8192 Nov  8 22:47 pcbenv/
drwxrwxrwx+   2 Administ None         4096 Dec 14 11:09 pix/
drwxrwxrwx+   2 Administ None            0 Aug 15  2003 sbin/
drwxrwxrwx+  25 Administ None        12288 Dec 23 22:10 src/
drwxrwxrwx+   3 Administ None         8192 Nov 25 23:06 src_arc/
drwxrwxrwx+   4 Administ None        40960 Jan  3 12:18 tmp/
drwxrwxrwx+  23 Administ None         4096 Aug 15  2003 usr/
drwxrwxrwx+  12 Administ None         4096 Aug 15  2003 var/
drwxrwxrwx+   3 Administ None         8192 Aug 11 04:48 vey/
drwxrwxrwx+  41 Administ None        32768 Oct 30 05:35 win/

And yes, it really is Windows NT4 Workstation and is completely missing
all the vulnerable crap like MSIE that MS has forced down users throats
during the last 10 years. None the less, it still runs most application
software reliably (both ms-windows and unix).

I have considered attempting similar mad hackery with newer microsoft
operating systems like XP and Win2003 but it's simply not worth the time
and effort. It's not like Microsoft is willing to pay me to fix their
crap and even if they were, the would not like the way I fix it (i.e.
removing all of thier supposed technological enhancements like MSIE).

As you might notice from the "mkbt.idb" I even audited the mkbt program
with the IDA Pro disassembler by Ilfak Gulifanov
(http://www.hexblog.com and http://www.datarescue.com/idabase and
http://www.datarescue.com/cgi-local/ultimatebb.cgi) before replacing the
NT4 boot sector with the boot sector from Win2K to get past the boot
disk limitations.

It seems Ilfak is getting some (very well deserved) fame these days for
his hotfix to the new WMF vunerability.
http://it.slashdot.org/it/06/01/02/1153244.shtml?tid=201&tid=218
http://it.slashdot.org/it/06/01/03/1913252.shtml?tid=220&tid=109&tid=172&tid=218

Just because people like Ilfak and I don't have access to the microsoft
source code does not mean we are unable to do anything we want to the
system. It's just a lot more work. The real problem is releasing patches
for a proprietary product when we don't own the rights to it.

jcr

Reply | Threaded
Open this post in threaded view
|

Re: "DadOS" - sys shutdown with XDM

Otto Moerbeek
In reply to this post by dfeustel
On Tue, 3 Jan 2006, Dave Feustel wrote:

> On Tuesday 03 January 2006 17:11, J.C. Roberts wrote:
>
> > The rule of thumb for granting privileges is simple; avoid granting
> > permissions whenever possible.
>
> Check the ownership/privileges on /tmp/.X11-unix/X0 after you start kde or Xorg.

Come on, this is a unix domain socket, as has been pointed out before.
You keep on repeating this nonsense. Having a world writable socket is
not a problem in itself. X has it's own authentication/authorization
scheme, which is used both for unix domain sockets and tcp sockets.

> Also check the ownership/privileges on the /dev/[pt]typ* pair allocated
> to any konsole session running under kde on openbsd.

Now that is likely a problem. A workaround is to use xterm instead
of konsole.

        -Otto

Reply | Threaded
Open this post in threaded view
|

Re: "DadOS" - sys shutdown with XDM

J.C. Roberts-2
In reply to this post by Hannah Schroeter
On Tue, 3 Jan 2006 22:46:50 +0100, Hannah Schroeter <[hidden email]>
wrote:

>Hello!
>
>On Tue, Jan 03, 2006 at 11:15:46AM -0800, patrick ~ wrote:
>>> The first thing I did was add a "flag file" to my dad's home directory
>>> and made sure he cant modify or delete it.
>
>>>   # touch /home/dad/.xshutdown
>>>   # chown root:wheel /home/dad/.xshutdown
>>>   # chmod 400 /home/dad/.xshutdown
>
>>login: dad
>>password: ********
>>dadsbox $ ls -l .xshutdown
>>-r--------    1 root     wheel           0 Jan  3 11:11 .xshutdown
>>dadsbox $ mv .xshutdown /tmp
>>dadsbox $ echo ":-)"
>>:-)
>
>>Assuming, of course, that /tmp and /home are
>>one partition.
>
>If not, mv .xshutdown .xnoshutdown is enough too.
>
>But then, chflags schg .xshutdown may be enough.
>

Yep, I totally forgot to use chflags to make the file immutable.

Thanks,
jcr

Reply | Threaded
Open this post in threaded view
|

Re: "DadOS" - sys shutdown with XDM

dfeustel
In reply to this post by Otto Moerbeek
On Tuesday 03 January 2006 17:50, Otto Moerbeek wrote:

>
> On Tue, 3 Jan 2006, Dave Feustel wrote:
>
> > On Tuesday 03 January 2006 17:11, J.C. Roberts wrote:
> >
> > > The rule of thumb for granting privileges is simple; avoid granting
> > > permissions whenever possible.
> >
> > Check the ownership/privileges on /tmp/.X11-unix/X0 after you start kde or Xorg.
>
> Come on, this is a unix domain socket, as has been pointed out before.
> You keep on repeating this nonsense. Having a world writable socket is
> not a problem in itself. X has it's own authentication/authorization
> scheme, which is used both for unix domain sockets and tcp sockets.

I confess that I do not understand the ramifications of the world rw+suid
permissions on this socket. I do wonder why this socket has world rw when
it seems to work equally well after I do a chmod 4700 on it at the beginning
of every kde session. Do not the permissions applied to this socket violate
the principle of least privilege mentioned above?
 
> > Also check the ownership/privileges on the /dev/[pt]typ* pair allocated
> > to any konsole session running under kde on openbsd.
>
> Now that is likely a problem. A workaround is to use xterm instead
> of konsole.
>
> -Otto
>

--
Lose, v., experience a loss, get rid of, "lose the weight"
Loose, adj., not tight, let go, free, "loose clothing"

Reply | Threaded
Open this post in threaded view
|

Re: "DadOS" - sys shutdown with XDM

Damien Miller
In reply to this post by dfeustel
Dave Feustel wrote:

> Check the ownership/privileges on /tmp/.X11-unix/X0 after you start kde or Xorg.

You can stop repeating this now, you have already demonstrated your
ignorance.

Reply | Threaded
Open this post in threaded view
|

Re: "DadOS" - sys shutdown with XDM

J.C. Roberts-2
In reply to this post by dfeustel
On Tue, 03 Jan 2006 17:34:57 -0500, Dave Feustel
<[hidden email]> wrote:

>On Tuesday 03 January 2006 17:11, J.C. Roberts wrote:
>
>> The rule of thumb for granting privileges is simple; avoid granting
>> permissions whenever possible.
>
>Check the ownership/privileges on /tmp/.X11-unix/X0 after you start kde or Xorg.
>

Whether or not the socket permissions and ownership are really a problem
depends on your point of view. Most folks consider it to be just fine
the way it is but as always, further investigation might prove
otherwise. X11 has it's own permissions system and my understanding of
it is negligible.

>Also check the ownership/privileges on the /dev/[pt]typ* pair allocated
>to any konsole session running under kde on openbsd.

This is a problem, well, at least it is according to my personal point
of view. ;-)

Have you isolated the code causing this behavior?

I'm not really a KDE user. Heck, I even resist installing X11 whenever
possible.

jcr

Reply | Threaded
Open this post in threaded view
|

Re: "DadOS" - sys shutdown with XDM

dfeustel
On Tuesday 03 January 2006 18:20, J.C. Roberts wrote:
> I'm not really a KDE user. Heck, I even resist installing X11 whenever
> possible.

I am getting ever closer to adopting your point of view re X11 and KDE.
--
Lose, v., experience a loss, get rid of, "lose the weight"
Loose, adj., not tight, let go, free, "loose clothing"

Reply | Threaded
Open this post in threaded view
|

Re: "DadOS" - sys shutdown with XDM

Otto Moerbeek
In reply to this post by dfeustel
On Tue, 3 Jan 2006, Dave Feustel wrote:

> On Tuesday 03 January 2006 17:50, Otto Moerbeek wrote:
> >
> > On Tue, 3 Jan 2006, Dave Feustel wrote:
> >
> > > On Tuesday 03 January 2006 17:11, J.C. Roberts wrote:
> > >
> > > > The rule of thumb for granting privileges is simple; avoid granting
> > > > permissions whenever possible.
> > >
> > > Check the ownership/privileges on /tmp/.X11-unix/X0 after you start kde or Xorg.
> >
> > Come on, this is a unix domain socket, as has been pointed out before.
> > You keep on repeating this nonsense. Having a world writable socket is
> > not a problem in itself. X has it's own authentication/authorization
> > scheme, which is used both for unix domain sockets and tcp sockets.
>
> I confess that I do not understand the ramifications of the world rw+suid
> permissions on this socket. I do wonder why this socket has world rw when
> it seems to work equally well after I do a chmod 4700 on it at the beginning
> of every kde session. Do not the permissions applied to this socket violate
> the principle of least privilege mentioned above?

It does not have suid permissions. This clearly shows you understand
little about permissions. Hint: it's a socket, starting with an 's'.

The princpiple is not violated, because having the socket writable for
others has it's uses, maybe?

        -Otto

12