Re: [CHANGE PROPOSAL] The securetty file is empty by default
On Wed, Apr 09, 2014 at 10:20:36PM +0200, Lennart Poettering wrote: On Wed, 02.04.14 09:12, quickbooks office (quickbooks.off...@gmail.com) wrote: [CHANGE PROPOSAL] The securetty file is empty by default All the info has been sitting here @ https://fedoraproject.org/wiki/Changes/securetty_file_is_empty_by_default since March 20th. Did I mess something up? Or is there just a backlog? This sounds entirely backwards, and I'd instead vote for removing securetty from the PAM stacks we ship altogether. The concept is outdated. It was useful in a time where the primary way to access a server was via physically attached TTY devices. But that time is mostly over... Nowadays the device names exposed by the kernel tend to be dynamically assigned, they should not be assumed stable (with one exeption, classic UART 16650 serial ports). Stable paths for these devices we add in via symlinks these days, using /dev/*/by-path/, /dev/*/by-id/, -- as you might know from disk devices. Now, the securetty logic is unable to verify things using these symlinks, hence the entire concept is flawed. It will use an unsteable device name instead, making it mostly useless in hotplug scenarios. securetty is particularly annoying when we use containers. Tools like machinectl login will dynamically spawn a getty for you on a pts device in the container, but since pts is not listed in securetty you cannot log in as root by default. And you cannot event add a wildcard match of pts/* to it, to make this work nicely. Yep, the securetty file is one of only 2 remaining blockers for getting login working out of the box in containers. Removing securetty would be a great help there given the inability to wildcard pts/*. The other problem is of course the horrible pam audit module, which the kernel guys are hopefully working towards a solution for. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [CHANGE PROPOSAL] The securetty file is empty by default
On Wed, 02.04.14 09:12, quickbooks office (quickbooks.off...@gmail.com) wrote: [CHANGE PROPOSAL] The securetty file is empty by default All the info has been sitting here @ https://fedoraproject.org/wiki/Changes/securetty_file_is_empty_by_default since March 20th. Did I mess something up? Or is there just a backlog? This sounds entirely backwards, and I'd instead vote for removing securetty from the PAM stacks we ship altogether. The concept is outdated. It was useful in a time where the primary way to access a server was via physically attached TTY devices. But that time is mostly over... Nowadays the device names exposed by the kernel tend to be dynamically assigned, they should not be assumed stable (with one exeption, classic UART 16650 serial ports). Stable paths for these devices we add in via symlinks these days, using /dev/*/by-path/, /dev/*/by-id/, -- as you might know from disk devices. Now, the securetty logic is unable to verify things using these symlinks, hence the entire concept is flawed. It will use an unsteable device name instead, making it mostly useless in hotplug scenarios. securetty is particularly annoying when we use containers. Tools like machinectl login will dynamically spawn a getty for you on a pts device in the container, but since pts is not listed in securetty you cannot log in as root by default. And you cannot event add a wildcard match of pts/* to it, to make this work nicely. Hence: please let's just remove securetty entirely from the default PAM stacks. It's annoying, it creates a false sense of security, it's a relict of a different time and not compatible with modern device management, hotplug, containers, and so on! Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [CHANGE PROPOSAL] The securetty file is empty by default
On Wed, Apr 09, 2014 at 10:20:36PM +0200, Lennart Poettering wrote: [technical reasoning snipped] Hence: please let's just remove securetty entirely from the default PAM stacks. It's annoying, it creates a false sense of security, it's a relict of a different time and not compatible with modern device management, hotplug, containers, and so on! That makes sense to me. And unlike tcpwrappers, it's just a runtime config file change to put back for cases where it's wanted. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org Tepid change for the somewhat better! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [CHANGE PROPOSAL] The securetty file is empty by default
Once upon a time, Matthew Miller mat...@fedoraproject.org said: On Wed, Apr 09, 2014 at 10:20:36PM +0200, Lennart Poettering wrote: [technical reasoning snipped] Hence: please let's just remove securetty entirely from the default PAM stacks. It's annoying, it creates a false sense of security, it's a relict of a different time and not compatible with modern device management, hotplug, containers, and so on! That makes sense to me. And unlike tcpwrappers, it's just a runtime config file change to put back for cases where it's wanted. Yeah, I think that's a decent way forward. AFAIK the securetty thing right now only affects console terminals and telnet logins. Since consoles are all in there, and hardly anybody runs a telnet server (I ran one on a couple of servers at PPOE to handle specific cases, but I wouldn't have had a problem with adding securetty checks if I needed it), it really is a meaningless check. -- Chris Adams li...@cmadams.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [CHANGE PROPOSAL] The securetty file is empty by default
On Wed, 9 Apr 2014, Chris Adams wrote: Once upon a time, Matthew Miller mat...@fedoraproject.org said: On Wed, Apr 09, 2014 at 10:20:36PM +0200, Lennart Poettering wrote: [technical reasoning snipped] Hence: please let's just remove securetty entirely from the default PAM stacks. It's annoying, it creates a false sense of security, it's a relict of a different time and not compatible with modern device management, hotplug, containers, and so on! That makes sense to me. And unlike tcpwrappers, it's just a runtime config file change to put back for cases where it's wanted. Yeah, I think that's a decent way forward. AFAIK the securetty thing right now only affects console terminals As long as it does not lock out root from kvm/uml console/serial logins. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [CHANGE PROPOSAL] The securetty file is empty by default
Once upon a time, Paul Wouters p...@nohats.ca said: On Wed, 9 Apr 2014, Chris Adams wrote: Once upon a time, Matthew Miller mat...@fedoraproject.org said: On Wed, Apr 09, 2014 at 10:20:36PM +0200, Lennart Poettering wrote: [technical reasoning snipped] Hence: please let's just remove securetty entirely from the default PAM stacks. It's annoying, it creates a false sense of security, it's a relict of a different time and not compatible with modern device management, hotplug, containers, and so on! That makes sense to me. And unlike tcpwrappers, it's just a runtime config file change to put back for cases where it's wanted. Yeah, I think that's a decent way forward. AFAIK the securetty thing right now only affects console terminals As long as it does not lock out root from kvm/uml console/serial logins. The proposal is to remove the securetty thing, which would remove any TTY check. root would be allowed on any TTY by default. -- Chris Adams li...@cmadams.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [CHANGE PROPOSAL] The securetty file is empty by default
On Wed, 09.04.14 22:20, Lennart Poettering (mzerq...@0pointer.de) wrote: This sounds entirely backwards, and I'd instead vote for removing securetty from the PAM stacks we ship altogether. The concept is outdated. It was useful in a time where the primary way to access a server was via physically attached TTY devices. But that time is mostly over... Nowadays the device names exposed by the kernel tend to be dynamically assigned, they should not be assumed stable (with one exeption, classic UART 16650 serial ports). Stable paths for these devices we add in via symlinks these days, using /dev/*/by-path/, /dev/*/by-id/, -- as you might know from disk devices. Now, the securetty logic is unable to verify things using these symlinks, hence the entire concept is flawed. It will use an unsteable device name instead, making it mostly useless in hotplug scenarios. securetty is particularly annoying when we use containers. Tools like machinectl login will dynamically spawn a getty for you on a pts device in the container, but since pts is not listed in securetty you cannot log in as root by default. And you cannot event add a wildcard match of pts/* to it, to make this work nicely. Hence: please let's just remove securetty entirely from the default PAM stacks. It's annoying, it creates a false sense of security, it's a relict of a different time and not compatible with modern device management, hotplug, containers, and so on! To clarify this: while I believe dropping securetty from the default PAM config is the right thing to do, I am not vulunteering to do it. But I'd love to see somebody to pick this up! Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [CHANGE PROPOSAL] The securetty file is empty by default
On Wed, Apr 09, 2014 at 11:39:19PM +0200, Lennart Poettering wrote: To clarify this: while I believe dropping securetty from the default PAM config is the right thing to do, I am not vulunteering to do it. But I'd love to see somebody to pick this up! I looked, and I think this is just a change in util-linux package (not the source even; the pam files are packaged as separate sources) + a note in the release notes. It's not referenced in authconfig or anything. I guess maybe we'd also want to remove /etc/securetty to reduce confusion (since the normal semantics are that missing file = nothing blocked), that's in setup. But otherwise, I think it just comes down to filing an RFE and getting the util-linux maintainer on board. Probably best after this change proposal gets to FESCo — at that point, I'll put this forward as a counter-proposal. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org Tepid change for the somewhat better! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [CHANGE PROPOSAL] The securetty file is empty by default
On Thu, 3 Apr 2014 07:32:38 -0700, quickbooks office wrote: This change will not affect logging into the console using the local account and then doing su to get root privileges. Is there a problem with logging into the local user account and then typing su and the root password? Maybe if there is a problem with NIS or something... There's been many a time when I've needed to login as root on a tty. Andrew -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [CHANGE PROPOSAL] The securetty file is empty by default
On Wed, 2014-04-02 at 19:15 -0400, Matthew Miller wrote: On Wed, Apr 02, 2014 at 02:12:50PM -0400, Simo Sorce wrote: How does someone express strong disagreement to this change ? Posting here is a good start. You can also add a note in the FESCo ticket for approval once one is filed, and if you are incredibly passionate you can come to the FESCo meeting (although I'm hoping we can make those meetings more efficient, so that's not a good place for back and forth -- if possible we should work out the issues before the meeting). Ticket number ? This change makes it very hard to do necessary maintenance. I can understand blocking SSH login as root with password by default, but I do not understand what is the point of blocking console login as root. I assume that it's for a kiosk or public (or at least managed) lab situation. It makes sense for that, but I'm not convinced of a benefit otherwise, and I don't think that situation is the default I am not even sure it makes sense in a kiosk, unless people want to use password as their root password. But even if it made sense in that situation it is far from being a useful *default*. This kind of severely restricting measure is best left to hardening manuals. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [CHANGE PROPOSAL] The securetty file is empty by default
This change will not affect logging into the console using the local account and then doing su to get root privileges. Is there a problem with logging into the local user account and then typing su and the root password? You are as such prompted to make a local user account when doing an install from the Live CD. 3.1.4.2.2. Disabling Root Logins To further limit access to the root account, administrators can disable root logins at the console by editing the /etc/securetty file. This file lists all devices the root user is allowed to log into. If the file does not exist at all, the root user can log in through any communication device on the system, whether via the console or a raw network interface. This is dangerous, because a user can log in to his machine as root via Telnet, which transmits the password in plain text over the network. By default, Fedora's /etc/securetty file only allows the root user to log in at the console physically attached to the machine. To prevent root from logging in, remove the contents of this file by typing the following command: echo /etc/securetty Warning A blank /etc/securetty file does not prevent the root user from logging in remotely using the OpenSSH suite of tools because the console is not opened until after authentication. The change will NOT affect: Programs that do not log in as root, but perform administrative tasks through setuid or other mechanisms...The following programs are NOT PREVENTED from accessing the root account: su, sudo, ssh, scp, sftp On Thu, Apr 3, 2014 at 6:06 AM, Simo Sorce s...@redhat.com wrote: On Wed, 2014-04-02 at 19:15 -0400, Matthew Miller wrote: On Wed, Apr 02, 2014 at 02:12:50PM -0400, Simo Sorce wrote: How does someone express strong disagreement to this change ? Posting here is a good start. You can also add a note in the FESCo ticket for approval once one is filed, and if you are incredibly passionate you can come to the FESCo meeting (although I'm hoping we can make those meetings more efficient, so that's not a good place for back and forth -- if possible we should work out the issues before the meeting). Ticket number ? This change makes it very hard to do necessary maintenance. I can understand blocking SSH login as root with password by default, but I do not understand what is the point of blocking console login as root. I assume that it's for a kiosk or public (or at least managed) lab situation. It makes sense for that, but I'm not convinced of a benefit otherwise, and I don't think that situation is the default I am not even sure it makes sense in a kiosk, unless people want to use password as their root password. But even if it made sense in that situation it is far from being a useful *default*. This kind of severely restricting measure is best left to hardening manuals. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [CHANGE PROPOSAL] The securetty file is empty by default
Am 03.04.2014 16:32, schrieb quickbooks office: This change will not affect logging into the console using the local account and then doing su to get root privileges. Is there a problem with logging into the local user account and then typing su and the root password? i do *not* need a local user account on machines typically running without any local user and *if i need to login there* i do that *because* i need to maintain that machine as root and that is why i *do not* have a user besides root because all other users for cronjobs and services have no shell at all so no, don't break useful setups with defaults signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [CHANGE PROPOSAL] The securetty file is empty by default
On Thu, 2014-04-03 at 07:32 -0700, quickbooks office wrote: This change will not affect logging into the console using the local account and then doing su to get root privileges. What local account ? Is there a problem with logging into the local user account and then typing su and the root password? Yes, in most installation I do not have any local user, I have only users coming via LDAP, and if the problem I need to solve is that the LDAP part of the equation is broken I have no user to log in if root is disabled. You are as such prompted to make a local user account when doing an install from the Live CD. Which is not the only mean of installing, nor the main mean for me (I never used the LiveCD for installing). You are clearly making assumptions that do not hold for the general case. Simo. 3.1.4.2.2. Disabling Root Logins To further limit access to the root account, administrators can disable root logins at the console by editing the /etc/securetty file. This file lists all devices the root user is allowed to log into. If the file does not exist at all, the root user can log in through any communication device on the system, whether via the console or a raw network interface. This is dangerous, because a user can log in to his machine as root via Telnet, which transmits the password in plain text over the network. By default, Fedora's /etc/securetty file only allows the root user to log in at the console physically attached to the machine. To prevent root from logging in, remove the contents of this file by typing the following command: echo /etc/securetty Warning A blank /etc/securetty file does not prevent the root user from logging in remotely using the OpenSSH suite of tools because the console is not opened until after authentication. The change will NOT affect: Programs that do not log in as root, but perform administrative tasks through setuid or other mechanisms...The following programs are NOT PREVENTED from accessing the root account: su, sudo, ssh, scp, sftp On Thu, Apr 3, 2014 at 6:06 AM, Simo Sorce s...@redhat.com wrote: On Wed, 2014-04-02 at 19:15 -0400, Matthew Miller wrote: On Wed, Apr 02, 2014 at 02:12:50PM -0400, Simo Sorce wrote: How does someone express strong disagreement to this change ? Posting here is a good start. You can also add a note in the FESCo ticket for approval once one is filed, and if you are incredibly passionate you can come to the FESCo meeting (although I'm hoping we can make those meetings more efficient, so that's not a good place for back and forth -- if possible we should work out the issues before the meeting). Ticket number ? This change makes it very hard to do necessary maintenance. I can understand blocking SSH login as root with password by default, but I do not understand what is the point of blocking console login as root. I assume that it's for a kiosk or public (or at least managed) lab situation. It makes sense for that, but I'm not convinced of a benefit otherwise, and I don't think that situation is the default I am not even sure it makes sense in a kiosk, unless people want to use password as their root password. But even if it made sense in that situation it is far from being a useful *default*. This kind of severely restricting measure is best left to hardening manuals. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [CHANGE PROPOSAL] The securetty file is empty by default
Once upon a time, quickbooks office quickbooks.off...@gmail.com said: This change will not affect logging into the console using the local account and then doing su to get root privileges. The only local account on many (most?) systems with network authentication is root. -- Chris Adams li...@cmadams.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [CHANGE PROPOSAL] The securetty file is empty by default
On Thu, 3 Apr 2014, Simo Sorce wrote: On Thu, 2014-04-03 at 07:32 -0700, quickbooks office wrote: This change will not affect logging into the console using the local account and then doing su to get root privileges. What local account ? Is there a problem with logging into the local user account and then typing su and the root password? Yes, in most installation I do not have any local user +1 The ability to login as root over the (virtual) serial console is very important. If anything, securetty should include all those (virtual) serials ports per default. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [CHANGE PROPOSAL] The securetty file is empty by default
2014-04-03 15:06 GMT+02:00 Simo Sorce s...@redhat.com: On Wed, 2014-04-02 at 19:15 -0400, Matthew Miller wrote: On Wed, Apr 02, 2014 at 02:12:50PM -0400, Simo Sorce wrote: How does someone express strong disagreement to this change ? Posting here is a good start. You can also add a note in the FESCo ticket for approval once one is filed, and if you are incredibly passionate you can come to the FESCo meeting (although I'm hoping we can make those meetings more efficient, so that's not a good place for back and forth -- if possible we should work out the issues before the meeting). Ticket number ? The ticket will be filed around the end of the comment period (which hasn't even started for this change, because it hasn't been announced by the Wrangler), and visible to devel@ in the FESCo agenda mail usually sent about a day before the meeting. (Yes, you would need to do some work to track all of this. But you should expect FESCo members to carefully read all comments on the mailing list without having to explicitly raise concerns in the ticket.) Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [CHANGE PROPOSAL] The securetty file is empty by default
2014-04-02 20:12 GMT+02:00 Simo Sorce s...@redhat.com: On Wed, 2014-04-02 at 09:12 -0700, quickbooks office wrote: [CHANGE PROPOSAL] The securetty file is empty by default All the info has been sitting here @ https://fedoraproject.org/wiki/Changes/securetty_file_is_empty_by_default I often install machines with root only as my users are all in my FreeIPA/LDAP server and I expect to be able to login as root on the console for maintenance purposes. This change makes it very hard to do necessary maintenance. I can understand blocking SSH login as root with password by default, but I do not understand what is the point of blocking console login as root. In larger organizations there is a legitimate need to be able to attribute every action as root to a specific individual, which is easiest to do by requiring a login from a non-root account to establish the session, and then tracking actions done by that session. OTOH this all works reliably enough only with a non-default auditing setup, so restricting root logins by default is alone not at all sufficient. Please explain the logic of blocking console logins but allowing SSH logins, it is completely backwards. Of the various problems with the proposal[1], this one seems the easiest to fix :) Mirek [1] I'm not listing them here; I'd much rather have the Change officially announced and have the official comment period, instead of starting a tradition of pre-announcements. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [CHANGE PROPOSAL] The securetty file is empty by default
On 04/03/2014 10:32 AM, quickbooks office wrote: 3.1.4.2.2. Disabling Root Logins To further limit access to the root account, administrators can disable root logins at the console by editing the /etc/securetty file. This is done in the name of accountability, by forcing an administrative login through an account attributable to a specific person. This, however, only makes sense if there _actually_are_ such individual accounts on the system. Would this proposal be acceptable if it wasn't implemented if 'root' is the only account? I personally don't think even such amended proposal is a reasonable default configuration, because systems authenticating against a domain, and having only one local (root) account, could lock the admin out if something happens to the network or to the domain server. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [CHANGE PROPOSAL] The securetty file is empty by default
On Thu, Apr 3, 2014 at 2:46 PM, Przemek Klosowski przemek.klosow...@nist.gov wrote: On 04/03/2014 10:32 AM, quickbooks office wrote: 3.1.4.2.2. Disabling Root Logins To further limit access to the root account, administrators can disable root logins at the console by editing the /etc/securetty file. This is done in the name of accountability, by forcing an administrative login through an account attributable to a specific person. This, however, only makes sense if there _actually_are_ such individual accounts on the system. Would this proposal be acceptable if it wasn't implemented if 'root' is the only account? I personally don't think even such amended proposal is a reasonable default configuration, because systems authenticating against a domain, and having only one local (root) account, could lock the admin out if something happens to the network or to the domain server. It's worse: the admin could lock themselves out just by creating another user account. --Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[CHANGE PROPOSAL] The securetty file is empty by default
[CHANGE PROPOSAL] The securetty file is empty by default All the info has been sitting here @ https://fedoraproject.org/wiki/Changes/securetty_file_is_empty_by_default since March 20th. Did I mess something up? Or is there just a backlog? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [CHANGE PROPOSAL] The securetty file is empty by default
On 04/02/2014 04:12 PM, quickbooks office wrote: [CHANGE PROPOSAL] The securetty file is empty by default All the info has been sitting here @ https://fedoraproject.org/wiki/Changes/securetty_file_is_empty_by_default since March 20th. Did I mess something up? Or is there just a backlog? I think it would just be better to remove it along with pam_securetty.so altogether as opposed to be shipping it empty JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [CHANGE PROPOSAL] The securetty file is empty by default
- Original Message - [CHANGE PROPOSAL] The securetty file is empty by default All the info has been sitting here @ https://fedoraproject.org/wiki/Changes/securetty_file_is_empty_by_default since March 20th. Did I mess something up? Or is there just a backlog? Backlog. But for this one, I'd really like to see some discussion in advance of the real announcement. So thank you for this email. Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [CHANGE PROPOSAL] The securetty file is empty by default
Once upon a time, Jaroslav Reznik jrez...@redhat.com said: - Original Message - [CHANGE PROPOSAL] The securetty file is empty by default All the info has been sitting here @ https://fedoraproject.org/wiki/Changes/securetty_file_is_empty_by_default since March 20th. Did I mess something up? Or is there just a backlog? Backlog. But for this one, I'd really like to see some discussion in advance of the real announcement. So thank you for this email. I'd be opposed to locking root out of the console login (having spent today at work tracking down miscellaneous VMs with only a root user created). Fedora still allows root SSH logins by default; how is that more secure than the console? -- Chris Adams li...@cmadams.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [CHANGE PROPOSAL] The securetty file is empty by default
Am 02.04.2014 19:29, schrieb Chris Adams: Once upon a time, Jaroslav Reznik jrez...@redhat.com said: - Original Message - [CHANGE PROPOSAL] The securetty file is empty by default All the info has been sitting here @ https://fedoraproject.org/wiki/Changes/securetty_file_is_empty_by_default since March 20th. Did I mess something up? Or is there just a backlog? Backlog. But for this one, I'd really like to see some discussion in advance of the real announcement. So thank you for this email. I'd be opposed to locking root out of the console login (having spent today at work tracking down miscellaneous VMs with only a root user created) +1 a golden-master for a virtual infrastructure usually do not have any other login user because which one is decided after clone and intention of the final machine instead some generic user Fedora still allows root SSH logins by default; how is that more secure than the console? it is not but disable that in a default install makes nothing more secure the only secure SSH setup is that one where no password login is allowed and that is a chicken/egg problem not solveable at setup signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [CHANGE PROPOSAL] The securetty file is empty by default
On Wed, 2014-04-02 at 09:12 -0700, quickbooks office wrote: [CHANGE PROPOSAL] The securetty file is empty by default All the info has been sitting here @ https://fedoraproject.org/wiki/Changes/securetty_file_is_empty_by_default since March 20th. Did I mess something up? Or is there just a backlog? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct How does someone express strong disagreement to this change ? I often install machines with root only as my users are all in my FreeIPA/LDAP server and I expect to be able to login as root on the console for maintenance purposes. This change makes it very hard to do necessary maintenance. I can understand blocking SSH login as root with password by default, but I do not understand what is the point of blocking console login as root. Please explain the logic of blocking console logins but allowing SSH logins, it is completely backwards. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [CHANGE PROPOSAL] The securetty file is empty by default
On Wed, Apr 02, 2014 at 02:12:50PM -0400, Simo Sorce wrote: How does someone express strong disagreement to this change ? Posting here is a good start. You can also add a note in the FESCo ticket for approval once one is filed, and if you are incredibly passionate you can come to the FESCo meeting (although I'm hoping we can make those meetings more efficient, so that's not a good place for back and forth -- if possible we should work out the issues before the meeting). This change makes it very hard to do necessary maintenance. I can understand blocking SSH login as root with password by default, but I do not understand what is the point of blocking console login as root. I assume that it's for a kiosk or public (or at least managed) lab situation. It makes sense for that, but I'm not convinced of a benefit otherwise, and I don't think that situation is the default -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org Tepid change for the somewhat better! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [CHANGE PROPOSAL] The securetty file is empty by default
On 2 April 2014 17:15, Matthew Miller mat...@fedoraproject.org wrote: On Wed, Apr 02, 2014 at 02:12:50PM -0400, Simo Sorce wrote: How does someone express strong disagreement to this change ? Posting here is a good start. You can also add a note in the FESCo ticket for approval once one is filed, and if you are incredibly passionate you can come to the FESCo meeting (although I'm hoping we can make those meetings more efficient, so that's not a good place for back and forth -- if possible we should work out the issues before the meeting). I haven't seen a ticket listed and the wiki entry does not mention one. I personally think it is a bad default having had to deal with this from people who did this with the old Bastille scripts and choosing the equivalent to SECURE EVERYTHING without knowing exactly what that idd no matter how many Do you really want to do that? popups. While it sounds like a useful task, it basically requires a bad sudo file and you are now having to use very complicated rescue steps to get back into the box (and if you added other things.. maybe not even that.) This change makes it very hard to do necessary maintenance. I can understand blocking SSH login as root with password by default, but I do not understand what is the point of blocking console login as root. I assume that it's for a kiosk or public (or at least managed) lab situation. It makes sense for that, but I'm not convinced of a benefit otherwise, and I don't think that situation is the default -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org Tepid change for the somewhat better! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Stephen J Smoogen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
