Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 16 Nov 1998 07:29:37 +0100
From:      Andre Albsmeier <andre.albsmeier@mchp.siemens.de>
To:        Warner Losh <imp@village.org>, Andre Albsmeier <andre.albsmeier@mchp.siemens.de>
Cc:        Matthew Dillon <dillon@apollo.backplane.com>, freebsd-security@FreeBSD.ORG
Subject:   Re: Would this make FreeBSD more secure?
Message-ID:  <19981116072937.E969@internal>
In-Reply-To: <199811152210.PAA01604@harmony.village.org>; from Warner Losh on Sun, Nov 15, 1998 at 03:10:26PM -0700
References:  <19981115192224.A29686@internal> <19981115161548.A23869@internal> <199811151758.JAA15108@apollo.backplane.com> <19981115192224.A29686@internal> <199811152210.PAA01604@harmony.village.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Nov 15, 1998 at 03:10:26PM -0700, Warner Losh wrote:
> In message <19981115192224.A29686@internal> Andre Albsmeier writes:
> : > 	* xterm		(suid root for utmp access)
> : 
> : Yes, this is another candidate. Is the setuid root permission really only
> : used to access /var/run/utmp?
> 
> No.  xterm uses it to chown the pty to the user.  It would be hard for
> the device to chown itself when opened, since devices operate below
> the file system....  xterm tosses its setuid-ness quickly.  There is a
> window in xterm for attack, should it do its data copies or file
> creation in a sloppy manner.

I see, thanks.

> I don't think that low port binding restrictions would be worth it.
> What does it really buy you?  Little, imho.  If an intruder breaks the
> ...

> Back to the original thread, I'm not sure how making more programs
> setgid would help system security.  Small ones that are easy to audit

Well, if you make it setgid and use 640 on the password file, you
a) can't write to the pw file directly any more
b) have to crack the root pw from the still readable pw file in order
   to become root.

Now you are root immediately.

> have proven, in the past, that too many programmers don't know how to
> use C's APIs in the face of a malicious attacker[*].  Larger programs
> seem to me to be asking for trouble.  Problems may also arise in the
> long term as the pw acquires new meanings that early adapters weren't
> aware of.  Look at how /etc/shells has grown from just being those
> users that can login to ftp, to being much, much more...

BTW, by examining the xlockmore configure file I found that I am not
the first one thinking of it:

---------------------------- snip ------------------------------

    if test -e /etc/shadow ; then
      INSTPGMFLAGS="-g shadow -m 2111"
      case `ls -l /etc/shadow` in
        -???r?????\ *\ shadow\ *\ /etc/shadow)  # group shadow can read it
          INSTPGMFLAGS="-g shadow -m 2111"
          ;;
        *)       
          INSTPGMFLAGS="-o root -m 4111"
          ;;
      esac       

---------------------------- snap ----------------------------

	-Andre

> 
> Warner

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19981116072937.E969>