diff mbox

[1/1] skeleton: add default login port to /etc/securetty

Message ID 1342149545-10417-1-git-send-email-roylee17@gmail.com
State Superseded
Headers show

Commit Message

Tzu-Jung Lee July 13, 2012, 3:19 a.m. UTC 
From: Tzu-Jung Lee <tjlee@ambarella.com>

We ran into a "Login incorrect" problem when running the same rootfs
image across platforms with different loging ports ttyS0/1/2/3.

Simply assignning "console" to BR2_TARGET_GENERIC_GETTY_PORT, which in
turn modifies the /etc/inittab, is not enough because the "console" device
was missing in the /etc/securetty.

While current securetty has enumerated a lot of ttys, this patch should save
some efforts to enumerate more.

Change-Id: Ifb1239c80eb86528345b24eb8d04b52b67aa1209
Signed-off-by: Tzu-Jung Lee <tjlee@ambarella.com>
---
 target/generic/Makefile.in |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

Comments

Arnout Vandecappelle July 14, 2012, 4:56 p.m. UTC | #1 
On 07/13/12 05:19, roylee17@gmail.com wrote:
> From: Tzu-Jung Lee<tjlee@ambarella.com>
>
> We ran into a "Login incorrect" problem when running the same rootfs
> image across platforms with different loging ports ttyS0/1/2/3.
>
> Simply assignning "console" to BR2_TARGET_GENERIC_GETTY_PORT, which in
> turn modifies the /etc/inittab, is not enough because the "console" device
> was missing in the /etc/securetty.
>
> While current securetty has enumerated a lot of ttys, this patch should save
> some efforts to enumerate more.
>
> Change-Id: Ifb1239c80eb86528345b24eb8d04b52b67aa1209
> Signed-off-by: Tzu-Jung Lee<tjlee@ambarella.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>

  But perhaps it's even better to remove securetty completely?  If it just
enumerates all possible ttys (even non-existent ones), it doesn't really add
security...  (Note: I haven't verified if util-linux's login allows root login if
/etc/securetty is missing.)


  Regards,
  Arnout
Thomas Petazzoni July 14, 2012, 5:15 p.m. UTC | #2 
Le Sat, 14 Jul 2012 18:56:51 +0200,
Arnout Vandecappelle <arnout@mind.be> a écrit :

>   But perhaps it's even better to remove securetty completely?  If it just
> enumerates all possible ttys (even non-existent ones), it doesn't really add
> security...  (Note: I haven't verified if util-linux's login allows root login if
> /etc/securetty is missing.)

Or we just add the tty that is selected to have the getty on (i.e the
skeleton would no longer have a etc/securetty file, and it would only
be created with one entry, as done by the patch being discussed).

Thomas
Arnout Vandecappelle July 14, 2012, 9:20 p.m. UTC | #3 
On 07/14/12 19:15, Thomas Petazzoni wrote:
> Le Sat, 14 Jul 2012 18:56:51 +0200,
> Arnout Vandecappelle<arnout@mind.be>  a écrit :
>
> >    But perhaps it's even better to remove securetty completely?  If it just
> > enumerates all possible ttys (even non-existent ones), it doesn't really add
> > security...  (Note: I haven't verified if util-linux's login allows root login if
> > /etc/securetty is missing.)
>
> Or we just add the tty that is selected to have the getty on (i.e the
> skeleton would no longer have a etc/securetty file, and it would only
> be created with one entry, as done by the patch being discussed).

  I wouldn't like that.  I often use the default skeleton but override e.g.
inittab in the post-build script.  I can't be bothered with setting
BR2_TARGET_GENERIC_GETTY_PORT to empty.  So the result is
that a /etc/securetty would be created which bears no relation with
the actual login ports defined in inittab...  And all this happens on the
sly, without any consent from the user or warning in the config menus.

  Bottom line: automatically adding BR2_TARGET_GENERIC_GETTY_PORT
to securetty is OK for me, but emptying it is not.

  BTW I can't think of many circumstances where securetty makes sense
on an embedded system to begin with: why would you allow shell login
on some port but not root login?

  Regards,
  Arnout
Thomas Petazzoni July 14, 2012, 11:08 p.m. UTC | #4 
Le Sat, 14 Jul 2012 23:20:50 +0200,
Arnout Vandecappelle <arnout@mind.be> a écrit :

>   I wouldn't like that.  I often use the default skeleton but override e.g.
> inittab in the post-build script.  I can't be bothered with setting
> BR2_TARGET_GENERIC_GETTY_PORT to empty.  So the result is
> that a /etc/securetty would be created which bears no relation with
> the actual login ports defined in inittab...  And all this happens on the
> sly, without any consent from the user or warning in the config menus.
> 
>   Bottom line: automatically adding BR2_TARGET_GENERIC_GETTY_PORT
> to securetty is OK for me, but emptying it is not.

Hmm, ok. But if you're modifying the inittab through a post-build
script, we could also say that it's your responsibility to also
adjust /etc/securetty accordingly, no?

I don't have a strong opinion here, just trying to find the right
balance.

>   BTW I can't think of many circumstances where securetty makes sense
> on an embedded system to begin with: why would you allow shell login
> on some port but not root login?

Is removing /etc/securetty sufficient? Both for Busybox getty, the
full-featured getty, and things like dropbear, openssh, telnet and al?
I think telnet needs pts/[0-n] to be in /etc/securetty otherwise it
doesn't allow root login.

Regards,

Thomas
Arnout Vandecappelle July 15, 2012, 12:28 a.m. UTC | #5 
On 07/15/12 01:08, Thomas Petazzoni wrote:
> Le Sat, 14 Jul 2012 23:20:50 +0200,
> Arnout Vandecappelle<arnout@mind.be>  a écrit :
>
> >    I wouldn't like that.  I often use the default skeleton but override e.g.
> > inittab in the post-build script.  I can't be bothered with setting
> > BR2_TARGET_GENERIC_GETTY_PORT to empty.  So the result is
> > that a /etc/securetty would be created which bears no relation with
> > the actual login ports defined in inittab...  And all this happens on the
> > sly, without any consent from the user or warning in the config menus.
> >
> >    Bottom line: automatically adding BR2_TARGET_GENERIC_GETTY_PORT
> > to securetty is OK for me, but emptying it is not.
>
> Hmm, ok. But if you're modifying the inittab through a post-build
> script, we could also say that it's your responsibility to also
> adjust /etc/securetty accordingly, no?

  Maybe, but if the securetty file isn't even part of the skeleton it's less
obvious.  But more importantly: people will send questions to the mailing
list asking why they can't log in into their buildroot system...

> I don't have a strong opinion here, just trying to find the right
> balance.
>
> >    BTW I can't think of many circumstances where securetty makes sense
> > on an embedded system to begin with: why would you allow shell login
> > on some port but not root login?
> Is removing /etc/securetty sufficient? Both for Busybox getty, the
> full-featured getty, and things like dropbear, openssh, telnet and al?
> I think telnet needs pts/[0-n] to be in /etc/securetty otherwise it
> doesn't allow root login.

  I did a search for securetty in a build of an allyesconfig, and only found it in
util-linux and busybox.  And I verified (by source code inspection) that util-linux
accepts an absent securetty.

  pam has a securetty module, but we don't support pam yet.  And anyway:
<http://git.fedorahosted.org/git?p=linux-pam.git;a=blob;f=modules/pam_securetty/pam_securetty.c;h=5f2d1bec32c98fe8e3cbf437aec105d8b28dcfc9;hb=HEAD#l113>  
if (stat(SECURETTY_FILE, &ttyfileinfo)) {
<http://git.fedorahosted.org/git?p=linux-pam.git;a=blob;f=modules/pam_securetty/pam_securetty.c;h=5f2d1bec32c98fe8e3cbf437aec105d8b28dcfc9;hb=HEAD#l114>      
pam_syslog(pamh, LOG_NOTICE, "Couldn't open %s: %m", SECURETTY_FILE);
<http://git.fedorahosted.org/git?p=linux-pam.git;a=blob;f=modules/pam_securetty/pam_securetty.c;h=5f2d1bec32c98fe8e3cbf437aec105d8b28dcfc9;hb=HEAD#l115>    
return PAM_SUCCESS; /* for compatibility with old securetty handling,
<http://git.fedorahosted.org/git?p=linux-pam.git;a=blob;f=modules/pam_securetty/pam_securetty.c;h=5f2d1bec32c98fe8e3cbf437aec105d8b28dcfc9;hb=HEAD#l116>                           
this needs to succeed.  But we still log the
<http://git.fedorahosted.org/git?p=linux-pam.git;a=blob;f=modules/pam_securetty/pam_securetty.c;h=5f2d1bec32c98fe8e3cbf437aec105d8b28dcfc9;hb=HEAD#l117>                           
error. */
<http://git.fedorahosted.org/git?p=linux-pam.git;a=blob;f=modules/pam_securetty/pam_securetty.c;h=5f2d1bec32c98fe8e3cbf437aec105d8b28dcfc9;hb=HEAD#l118>  
}

  Regards,
  Arnout
Tzu-Jung Lee July 30, 2012, 3:13 p.m. UTC | #6 
On Sun, Jul 15, 2012 at 8:28 AM, Arnout Vandecappelle <arnout@mind.be> wrote:
> On 07/15/12 01:08, Thomas Petazzoni wrote:
>>
>> Le Sat, 14 Jul 2012 23:20:50 +0200,
>> Arnout Vandecappelle<arnout@mind.be>  a écrit :
>>
>> >    I wouldn't like that.  I often use the default skeleton but override
>> > e.g.
>> > inittab in the post-build script.  I can't be bothered with setting
>> > BR2_TARGET_GENERIC_GETTY_PORT to empty.  So the result is
>> > that a /etc/securetty would be created which bears no relation with
>> > the actual login ports defined in inittab...  And all this happens on
>> > the
>> > sly, without any consent from the user or warning in the config menus.
>> >
>> >    Bottom line: automatically adding BR2_TARGET_GENERIC_GETTY_PORT
>> > to securetty is OK for me, but emptying it is not.
>>
>> Hmm, ok. But if you're modifying the inittab through a post-build
>> script, we could also say that it's your responsibility to also
>> adjust /etc/securetty accordingly, no?
>
>
>  Maybe, but if the securetty file isn't even part of the skeleton it's less
> obvious.  But more importantly: people will send questions to the mailing
> list asking why they can't log in into their buildroot system...
>
>
>> I don't have a strong opinion here, just trying to find the right
>> balance.
>>
>> >    BTW I can't think of many circumstances where securetty makes sense
>> > on an embedded system to begin with: why would you allow shell login
>> > on some port but not root login?
>> Is removing /etc/securetty sufficient? Both for Busybox getty, the
>> full-featured getty, and things like dropbear, openssh, telnet and al?
>> I think telnet needs pts/[0-n] to be in /etc/securetty otherwise it
>> doesn't allow root login.
>
>
>  I did a search for securetty in a build of an allyesconfig, and only found
> it in
> util-linux and busybox.  And I verified (by source code inspection) that
> util-linux
> accepts an absent securetty.
>
>  pam has a securetty module, but we don't support pam yet.  And anyway:
> <http://git.fedorahosted.org/git?p=linux-pam.git;a=blob;f=modules/pam_securetty/pam_securetty.c;h=5f2d1bec32c98fe8e3cbf437aec105d8b28dcfc9;hb=HEAD#l113>
> if (stat(SECURETTY_FILE, &ttyfileinfo)) {
> <http://git.fedorahosted.org/git?p=linux-pam.git;a=blob;f=modules/pam_securetty/pam_securetty.c;h=5f2d1bec32c98fe8e3cbf437aec105d8b28dcfc9;hb=HEAD#l114>
> pam_syslog(pamh, LOG_NOTICE, "Couldn't open %s: %m", SECURETTY_FILE);
> <http://git.fedorahosted.org/git?p=linux-pam.git;a=blob;f=modules/pam_securetty/pam_securetty.c;h=5f2d1bec32c98fe8e3cbf437aec105d8b28dcfc9;hb=HEAD#l115>
> return PAM_SUCCESS; /* for compatibility with old securetty handling,
> <http://git.fedorahosted.org/git?p=linux-pam.git;a=blob;f=modules/pam_securetty/pam_securetty.c;h=5f2d1bec32c98fe8e3cbf437aec105d8b28dcfc9;hb=HEAD#l116>
> this needs to succeed.  But we still log the
> <http://git.fedorahosted.org/git?p=linux-pam.git;a=blob;f=modules/pam_securetty/pam_securetty.c;h=5f2d1bec32c98fe8e3cbf437aec105d8b28dcfc9;hb=HEAD#l117>
> error. */
> <http://git.fedorahosted.org/git?p=linux-pam.git;a=blob;f=modules/pam_securetty/pam_securetty.c;h=5f2d1bec32c98fe8e3cbf437aec105d8b28dcfc9;hb=HEAD#l118>
> }

Hi Guys,

Sorry for the late follow-ups, but it seems that the original patch
should be okay for being merged, right?
Or any other way can I make an improvement?

Thanks,
Roy

--
And sorry to Arnout for duplicating the mails because I forgot to
include the mailiing list...
diff mbox

Patch

diff --git a/target/generic/Makefile.in b/target/generic/Makefile.in
index 4185202..571b54a 100644
--- a/target/generic/Makefile.in
+++ b/target/generic/Makefile.in
@@ -31,6 +31,9 @@  target-generic-do-remount-rw:
 target-generic-dont-remount-rw:
 	$(SED) '/^[^#].*# REMOUNT_ROOTFS_RW$$/s~^~#~' $(TARGET_DIR)/etc/inittab
 
+target-generic-securetty:
+	grep -q $(TARGET_GENERIC_GETTY) $(TARGET_DIR)/etc/securetty || echo $(TARGET_GENERIC_GETTY) >> $(TARGET_DIR)/etc/securetty
+
 ifneq ($(TARGET_GENERIC_HOSTNAME),)
 TARGETS += target-generic-hostname
 endif
@@ -50,4 +53,7 @@  TARGETS += target-generic-do-remount-rw
 else
 TARGETS += target-generic-dont-remount-rw
 endif
+ifneq ($(TARGET_GENERIC_GETTY),)
+TARGETS += target-generic-securetty
+endif
 endif