similar to: tty chowning

x-kernel@vger.rutgers.edu Subject: Re: tty chowning Newsgroups: mail.linux.kernel In-Reply-To: <199709261901.PAA04763@dcl.MIT.EDU> Organization: Cc: Bcc: "Theodore Y. Ts''o" <tytso@MIT.EDU> writes: > David Holland <dholland@eecs.harvard.edu> writes: > } Why not build chowning into this process? On TIOCSCTTY, the tty would > } chown itself to the

It seems that when you send rwhod an rwho packet, it blindly assumes you are who the packet says you are. That is to say, it looks as if any host can inject false rwho data for any other host. I''m not convinced this is worth fixing. Opinions? -- - David A. Holland | VINO project home page: dholland@eecs.harvard.edu | http://www.eecs.harvard.edu/vino

Some versions (the util-linux version, but not the netwrite or netkit versions) of /usr/bin/write have a buffer overrun problem that is almost certainly exploitable. Note that this gives access to the tty group, but not (directly) root. The fix is to change the two sprintfs to snprintfs. Patches have been mailed to the maintainer. -- - David A. Holland | VINO project home page:

> ========================================================================== > CERT(sm) Advisory CA-96.20 > Original issue date: September 18, 1996 > Last revised: -- > > Topic: Sendmail Vulnerabilities > -------------------------------------------------------------------------- > *** This advisory supersedes CA-95:05 *** Just a word of warning -

I guess I never sent the message I was going to last week about xterm. [Noteto REW: If I did, kill this message...] It seems that sending xterm an excessively long escape sequence kills it (and perchance might be made to hack it, which would be quite bad.) The xterm in XFree86-3.2 is immune to this problem. I recommend everyone upgrade ASAP. -- - David A. Holland | VINO

Hi. I don''t know if this one is known, but I can''t recall seeing anything about it. If it is old news I apologize. I discovered a bug in the inetd that comes with NetKit-B-0-08 and older. If a single SYN is sent to port 13 of the server, inetd will die of Broken Pipe: write(3, "Sun Jan 12 21:50:35 1997\r\n", 26) = -1 EPIPE (Broken pipe) --- SIGPIPE (Broken pipe) ---

Marek Michalkiewicz <marekm@I17LINUXB.ISTS.PWR.WROC.PL> wrote: : It seems that most of the RedHat 5.3.12 security patches are in the : standard 5.4.17, except for the patch below. Also, there are more : (different) fixes in 5.4.18 (check h_length against sizeof(sin_addr) : in inet/rcmd.c and inet/rexec.c). : + { : +

[Mod: This message is a reason *why* linux-security is moderated list. This is also a reason why Rogier, myself, Alan Cox and others really do not want to have completely open lists that deal with security related aspects of running a system as way too many people just jump to conclusions and give suggestions without doing any reasearch on a subject. -- alex (co-moderator of

[mod: Executive summary: SNI found recent linux-distributions not-vulnerable -- REW] -----BEGIN PGP SIGNED MESSAGE----- ###### ## ## ###### ## ### ## ## ###### ## # ## ## ## ## ### ## ###### . ## ## . ######.

I''ve been poking around my system, and realized that having a tftp server would be handy. (I''m working with cisco routers, which have the capability to up and download configuration images via tftp.) However, I''m not content with the usual tftpd that comes with Linux. The whole "specify each directory you want" scheme is cock-eyed to me. I''d prefer

OK, I got a chance to try out the Tru64 patch for privsep. I applied the patch to 3.4p1. Partial success, in that it now works for me for logins to "root". Logins to ordinary accounts fail after authentication, when trying to set tty characteristics. See the excerpt from the debug messages below. This is for Tru64 V4.0F (with enhanced_security turned on, obviously.) I guess it's time

[Note: this has already been sent to comp.os.linux.announce.] -----BEGIN PGP SIGNED MESSAGE----- It has come to my attention that the recent 1.6 release of MAKEDEV-C inadvertently created /dev/random and /dev/urandom with the wrong permissions. /dev/random and /dev/urandom should look like this: crw-r--r-- 1 root system 1, 8 Feb 21 14:42 /dev/random crw-r--r-- 1 root system

http://bugzilla.mindrot.org/show_bug.cgi?id=536 Summary: no access to tty on Linux 2.0 Product: Portable OpenSSH Version: 3.6p1 Platform: ix86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: openssh-unix-dev at mindrot.org ReportedBy: jfeise at

I'm trying to get OpenSSH 2.5.2p2 to run on HP-UX 9.05. I've had some decent results, but I'm also seeing some problems. I'm using the EGD (I configured with --with-prngd-socket=/tmp/entropy). * Compiling required some changes, which I've attached. Two of the changes are "hackish", and not at all suited to inclusion in the source tree, but they might point

I'm trying to change my local setup from ssh2 to openssh-2.3.0p1. I need captive comands and specific environments for each key, i.e. the "command=XXX" and "environment=X=y" options. Unfortunately I *also* need to support the existing ssh2 client for a transition period, since it's impractical to change all user's environments to openssh in one go. I have converted

Hi there I've just upgraded to openssh-3.2.2p1 from openssh-1.2.3 and am having some difficulties. On one of the platforms I'm using (linux kernel 2.2.19 with glibc 2.1.1) it works fine, but on another (linux kernel 2.2.20 with glibc 2.0.7) I get this in the syslog every time I log in: sshd[12277]: Accepted publickey for root from 212.38.67.158 port 2397 ssh2 PAM_pwdb[12277]: (sshd)

I am trying to get vino going on CentOS 7.1 I run this command: gsettings set org.gnome.Vino require-encryption false Then this one: gsettings list-recursively org.gnome.Vino org.gnome.Vino notify-on-connect true org.gnome.Vino alternative-port uint16 5900 org.gnome.Vino disable-background false org.gnome.Vino use-alternative-port false org.gnome.Vino icon-visibility 'client'

I''m looking for some evidence, backup up with dates and references, that shows that the Linux community responds to security problems more quickly than other OS vendors, and thus might be considered "more secure". A number of fairly high profile corporations are starting to look for such information as they consider Linux as an alternative solution to other UNIXes. Something

Don't know why it works, but it works ... Rich.

Doing this breaks bash in virt-rescue with the error: bash: cannot set terminal process group (-1): Inappropriate ioctl for device bash: no job control in this shell Also ^C etc does not work. Removing this ioctl call fixes this. I noticed the problem because supermin's init compiled with dietlibc worked, since the dietlibc header files don't define TIOCSCTTY and hence the ioctl