Message ID | 1342149545-10417-1-git-send-email-roylee17@gmail.com |
---|---|
State | Superseded |
Headers | show |
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
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
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
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
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
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 --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