[opensuse-factory] kmscon , pam_securetty and login
Hi: While testing kmscon, I noticed that, by default it is impossible to login as root. kmscon simple invokes login(1) binary which in interfaces with PAM module pam_securetty that checks for "secure ttys" in /etc/securetty which lists the permitted devices as a whitelist..but kmscon does not use the tty(4) but pts(4) and /dev/pts/* devices are not in the list. While I think this "whitelist" is a pretty arcane and ugly way to control access, I'm looking for feedback on how to make this stuff work without having to manually extend the whitelist (and therefore perpetuating the false sense of security it provides) AND not breaking the old way. Does anyone have any feedback on how to "bypass" this list programatically ? Cheers. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 2013-04-16 01:43, Cristian Rodríguez wrote:
While I think this [securetty] "whitelist" is a pretty arcane and ugly way to control access, I'm looking for feedback on how to make this stuff work without having to manually extend the whitelist (and therefore perpetuating the false sense of security it provides) AND not breaking the old way.
Does anyone have any feedback on how to "bypass" this list programatically ?
There are so many other ways of logging in as root remotely nowadays, does securetty still have meaning other than to block logins on modems not operating in Internet Protocol mode? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon 15 Apr 2013 11:37:26 PM CLST, Jan Engelhardt wrote:
There are so many other ways of logging in as root remotely nowadays, does securetty still have meaning other than to block logins on modems not operating in Internet Protocol mode?
As far as I know, that's the one of the meanings, the other is disallowing root login with telnet or something.. but I might be wrong, someone on the security team will probably have a better insight. Now, in the case it is only about that, I see no reason whatsoever to keep the check around anymore, for any purpose. I can imagine dozens of ways how to bypass this restriction nowdays.. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 16 Apr 2013 01:43, Cristian Rodríguez <crrodriguez@...> wrote:
Hi:
While testing kmscon, I noticed that, by default it is impossible to login as root. kmscon simple invokes login(1) binary which in interfaces with PAM module pam_securetty that checks for "secure ttys" in /etc/securetty which lists the permitted devices as a whitelist..but kmscon does not use the tty(4) but pts(4) and /dev/pts/* devices are not in the list.
While I think this "whitelist" is a pretty arcane and ugly way to control access, I'm looking for feedback on how to make this stuff work without having to manually extend the whitelist (and therefore perpetuating the false sense of security it provides) AND not breaking the old way.
Does anyone have any feedback on how to "bypass" this list programatically ?
AFAIK the /bin/login that is in use by OSS 12.3 does not link to pam_securetty directly. Thus the usual suspects for the needed changes are: - pam_securetty.so to allow pts/? in /etc/securetty or - pam-config files /etc/pam.d/{login,login.old,remote} For a 'try' system the removal of the pam_securetty.so calls in the pam-config files is OK, but on a proctive system out there, I think we want to have a replacement / extension for pam_securetty.so ATM kmscon is a very fresh child in terms of programming, and subject to change, so IMHO it would be the best to rise this issue with the programmers of kmscon directly and ask for ideas. OTOH kick this issue to the RedHat sec-team and watch the firework. - Yamaban, who is feeling vindictive on the issue.
El 16/04/13 05:07, Yamaban escribió:
AFAIK the /bin/login that is in use by OSS 12.3 does not link to pam_securetty directly.
I have never suggested that.. nothing links to pam_securetty, it is a pam module, not a general purpose shared library...
Thus the usual suspects for the needed changes are: - pam_securetty.so to allow pts/? in /etc/securetty or - pam-config files /etc/pam.d/{login,login.old,remote}
yes, disabling pam_securetty will work,that's not the point of this question, however.
ATM kmscon is a very fresh child in terms of programming, and subject to change, so IMHO it would be the best to rise this issue with the programmers of kmscon directly and ask for ideas.
It was already risen there,this has nothing to do with the kmscon code, it does nothing with pam, it does no authentication/autorization, it invokes "login" that's all.
OTOH kick this issue to the RedHat sec-team and watch the firework.
what has redhat to do this ? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 17 Apr 2013 00:40, Cristian Rodríguez <crrodriguez@...> wrote:
El 16/04/13 05:07, Yamaban escribió: [snip]
ATM kmscon is a very fresh child in terms of programming, and subject to change, so IMHO it would be the best to rise this issue with the programmers of kmscon directly and ask for ideas.
It was already risen there,this has nothing to do with the kmscon code, it does nothing with pam, it does no authentication/autorization, it invokes "login" that's all.
The question is why does kmscon use pts instead of tty. Is there a deeper cause (e.g. code quality inside kernel), or what was the driving thought? Are the aware of the shit storm due to login / pam that is coming? OTOH login and pam could do with an overhaul on the matter. The pure concept behind securetty is more than simply fishy. No, my thought behind rising the matter upstream is: To make sure all players (kmscon / login / pam) get their asses in gear BEFORE the fallout hits the masses / users via a misconfigured distro / packages. Early warning, and all that. A system where root can not log in during a boot with "single" or "emergency" target is a failure from the start.
OTOH kick this issue to the RedHat sec-team and watch the firework.
what has redhat to do this ?
Notice: where do Kai and Lennert work? Who wants for 'force' kmscon on the users before it's really ready (see above)? Let them handle the issue "inhouse" first. I had some ill feelings about their April first jokes, let them handle the fallout first has something poetic about "Karma", as I said, vidictive, I know. - Yamaban.
El 16/04/13 20:24, Yamaban escribió:
The question is why does kmscon use pts instead of tty. Is there a deeper cause (e.g. code quality inside kernel), or what was the driving thought?
for the start, kmscon is a terminal emulator, whose main purpose is to leave the old in-kernel virtual console behind.. which requires the tty subsytem...
Are the aware of the shit storm due to login / pam that is coming?
huh ?
No, my thought behind rising the matter upstream is: To make sure all players (kmscon / login / pam) get their asses in gear BEFORE the fallout hits the masses / users via a misconfigured distro / packages. Early warning, and all that. A system where root can not log in during a boot with "single" or "emergency" target is a failure from the start.
Turning off the lights in the old in-kernel virtual terminals is waaaaaaaaaaaaaaaaay down the list of tasks.. Do not expect the old thing to go away at anytime soon..
Notice: where do Kai and Lennert work?
Kay and Lennart have not written a single line of code of kmscon, kmscon is being developed by X/wayland developer(s). Also on this world, where people work is next to meaningless, prolific developers tend to work on place that will pay them to do what they want. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
В Tue, 16 Apr 2013 19:40:33 -0300 Cristian Rodríguez <crrodriguez@opensuse.org> пишет:
ATM kmscon is a very fresh child in terms of programming, and subject to change, so IMHO it would be the best to rise this issue with the programmers of kmscon directly and ask for ideas.
It was already risen there,this has nothing to do with the kmscon code,
It has. If it supposed to replace Linux console, it should also provide means to identify itself as Linux console. There are merits in "physical presence" check.
it does nothing with pam, it does no authentication/autorization, it invokes "login" that's all.
It fools login in providing no way to detect local session. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 04/16/2013 11:52 PM, Andrey Borzenkov wrote:
It has. If it supposed to replace Linux console, it should also provide means to identify itself as Linux console. There are merits in "physical presence" check.
Are you seriously suggesting a security check that relies on a software-only whitelist,which is enforced by a pam module (not by the kernel) is a valuable check for physical presence in year 2013 ? o_O valuable checks for physical presence for me consist smart cards, iris/face recognition..maybe fingerprints.. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 04/16/2013 11:52 PM, Andrey Borzenkov wrote: it should also provide
means to identify itself as Linux console.
It does, but it is not a bsd-style tty/console/whatever..hence not part of this arbitrary pam "whitelist" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Cristian Rodríguez wrote:
While testing kmscon, I noticed that, by default it is impossible to login as root. kmscon simple invokes login(1) binary which in interfaces with PAM module pam_securetty that checks for "secure ttys" in /etc/securetty which lists the permitted devices as a whitelist..but kmscon does not use the tty(4) but pts(4) and /dev/pts/* devices are not in the list.
While I think this "whitelist" is a pretty arcane and ugly way to control access, I'm looking for feedback on how to make this stuff work without having to manually extend the whitelist (and therefore perpetuating the false sense of security it provides) AND not breaking the old way.
Does anyone have any feedback on how to "bypass" this list programatically ?
According to the documentation pam_securetty is supposed to allow access from the currently active console. I suppose kmscon somehow needs to have the notion of an active console as well. So it needs to communicate that to the kernel to reflect it in /sys/class/tty/console/active. Alternatively pam_securetty could be patched to support kmscon directly. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 04/17/2013 04:06 AM, Ludwig Nussel wrote:
Cristian Rodríguez wrote:
/sys/class/tty/console/active.
heh.. its very purpose is to replace the "console" in the "tty" subsystem...:-) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Cristian Rodríguez wrote:
On 04/17/2013 04:06 AM, Ludwig Nussel wrote:
Cristian Rodríguez wrote:
/sys/class/tty/console/active.
heh.. its very purpose is to replace the "console" in the "tty" subsystem...:-)
Then I suppose it has other means to communicate the active console(s). pam_securetty has to be adjusted for that then. Same for systemd and potentially other programs that query the active console. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (5)
-
Andrey Borzenkov -
Cristian Rodríguez -
Jan Engelhardt -
Ludwig Nussel -
Yamaban