lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 7 Jun 2012 11:52:27 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Richard Weinberger <richard@....at>
Cc:	Boaz Harrosh <bharrosh@...asas.com>,
	user-mode-linux-devel@...ts.sourceforge.net,
	gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org,
	viro@...iv.linux.org.uk, jslaby@...e.cz, alan@...ux.intel.com
Subject: Re: [uml-devel] um: TTY fixes (?)

> > I really don't get it. You have not broken anything new. Only
> > not fixed all of the problems. Current code does not work for "non-tty0
> > terminals" as well right?
> 
> No, it works fine.

Not really. You happen to be lucky. Anyway with no tty port the UML code
will soon cease to function completely so a solution of some sort is
needed.
 
> > I don't see Alan's comment at all. This is not a regression it was always
> > like that. Ever since Fedora was working on UML, But these fixes are real
> > live regression crashes.
> > 
> > And I don't see the all "leaving other vendors systems insecure". It just
> > a freaking UML tty. You need to be root 5 times before you have access
> > to all these, and it's only the UML that's compromised not the "all system"
> > And surely the current plain tty0 crash is much less secure then this thing.
> 
> The "TTY problem" is not UML specific.

That one is. The console driver handles stuff its own way and
differently. It's eventually got to tackle the same problem.

I still think we ought to be able to solve it cleanly. It's a case of
getting the tests right so that we allow for the misbehaviour util-linux
does.

As of itself util-linux behaviour doesn't appear to be something we can't
permit as the 

	open
	vhangup

sequence means the file handle that is left from before the vhangup due
to util-linux misbehaving is a hung-up fd so cannot affect the tty.

UML is a good test case for fixing this properly because it's got almost
no users, and those it has are fairly technical 8)


Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ