Persisting /etc/securetty Contents

Latest response

STIG V-ID 38494 specifies that serial console devices should be ommitted from /etc/securetty. This is easily enough accomplished in any given CM framework by scanning the file an nuking any ttyS* entries. Unfortunately, when you reboot an EL6 system, upstart puts any GRUB-specified console entries back.

I've tried creating an /etc/login/serial.override file and ommitting the /sbin/securetty and fedora.serial-console-available entries. Similarly tried creating an /etc/init/ttyS0.conf line with those entry points ommitted. In either case, after reboot, ttyS0 is placed back into /etc/securetty.

Short of nuking the offending ttyS* entries and then doing a chattr -i /etc/securetty, is there any better way to prevent the entries from coming back? I'd really rather avoid the chattr work-around.

Responses

serial.override should be in /etc/init not /etc/loginwith permissions 644.

I would just add changes to override file.

Sorry, /etc/login was a mis-type: meant /etc/init (made my .override with a simple cp serial.conf serial.override in /etc/init then made my edits)

Unfortunately, on the EL 6.7 test-systems, it seems like the override file is ignored. On the plus side, the .conf file doesn't seem to get overridden.

The only issue with directly modifying the serial.conf is that any patch or update could squash your changes. That is why override files are advised.

Unfortunately, creating a serial.override file (with correct permissions and contexts) is simply ignored. That was what I tried to start with. Got stuck falling back on modding the .conf file (and using chattr to try to block an RPM overwrite action).

Unfortunately, creating a serial.override file (with correct permissions and contexts) is simply ignored. That was what I tried to start with. Got stuck falling back on modding the .conf file (and using chattr to try to block an RPM overwrite action).

Tom, I suspect the rpm update would still take place, but the file in question just would not get clobbered? is that correct? Thanks

Typically the system will chrip about the file but not fail the RPM install (previously builds I dealt with, the hardening tools would chattr the smb.conf file).

That said, it's a low-order risk of being clobbered by an update. The initscripts RPM is updated preeeetty infrequently.

Thanks Tom

My assumption is, without testing, the update will fail. The chattr would need to be removed, the file backed up then replace after the update. In practice, I have seen these types of issues, marked as "frozen" for at least the initscripts package along with system documentation on how to update the individual system. Maybe there is an yum or rpm force option, but would still provide some confusion to an unexpecting systems admin.

Yates,

I was curious and so i did a test of sorts... I did a reinstall of the rpm on a non-production system I cared little about using this... During the reinstall, with the "chattr +i /etc/init/serial.conf" it failed to restore a file [/etc/rc.local] I moved out of the way.

  • Before proceeding, make sure your conf file is identifiable, contains the edits you wish and probably make a backup of the file.
  • I wanted to see if after doing the "chattr" command against /etc/init/serial.conf file if it would still reinstall the rpm successfully. So I moved (mv command) the file at /etc/rc.local out of the way to see if it would reinstall the missing /etc/rc.local ...

However, it failed to restore the /etc/rc.local file and from what I found later, the chatter against the file "/etc/init/serial.conf" apparently (in my case) caused it to fail... I did not test this with a "yum update" (I would have had to do a "yum downgrade to do that first")

/bin/mv /etc/rc.local /etc/rc.local.bak
chattr +i /etc/init/serial.conf
yum -y reinstall initscripts -v

While this is not the same as an upgrade, here is what I got... -My output...

<output truncated>
Error unpacking rpm package initscripts-9.03.49.1.el6_7.2.x86_64
error: unpacking of archive failed on file /etc/init/serial.conf: cpio: rename
Warning: scriptlet or other non-fatal errors occurred during transaction.
Installed products updated.
   Verifying   : initscripts-9.03.49-1.el6_7.2.x86_64
What is this? initscripts-9.03.49-1.el6_7.2.x86_64
## it really said the above!!
VerifyTransaction time: 0.054
Transaction time: 5.341
Failed:
  initscripts.x86_64 0:9.03.49-1.el6_7.2

[me@mysystem] # file /etc/rc.local 

The "file command" failed because the "yum reinstall" command did not restore /etc/rc.local. However, when I did a chattr -i of the conf file,, and a "yum reinstall", it reinstalled initscripts rpm with no consternation

chattr -i /etc/init/serial.conf
yum -y reinstall initscripts

this worked and /etc/rc.local was restored, after doing the "chattr -i /etc/init/serial.conf" and another "yum reinstall".

Now maybe there is a difference with a yum update and yum reinstall.

Perhaps test again by going to a non-production system and do a "yum downgrade initscripts" then do the "chattr +i /etc/init/serial.conf" and watch the output of "yum -y -v update initscripts"

Or bypass that and put the configuration file into your satellite server under a configuration channel you create, and if there's a difference, redeploy it. if you have no satellite server, make a backup and redeploy if needed, or the method you and Tom spoke of with the ".overrride" file...

Agree on your last point. Satellite, Puppet, or even a persistent cron script that verifies the checksum of the file and overwrites on any change, might be a good approach.

Yes, that's what I do with the confs etc I care about

Results will also depend on whether something was declared a %doc or %config in the RPM (or possibly even handled via a %post scriptlet).

Given the nature of rc.local, it's unlikely to be restored by an RPM action (it's a file that's meant to contain local content: it would be bad juju if RPM blew it out of the way):

$ rpm -qc initscripts-9.03.49-1.el6.centos.3.x86_64 /etc/X11/prefdm /etc/adjtime /etc/inittab /etc/networks /etc/rc.d/rc.local /etc/rc.d/rc0.d/S00killall /etc/rc.d/rc0.d/S01halt /etc/rc.d/rc1.d/S99single /etc/rc.d/rc2.d/S99local /etc/rc.d/rc3.d/S99local /etc/rc.d/rc4.d/S99local /etc/rc.d/rc5.d/S99local /etc/rc.d/rc6.d/S00killall /etc/rc.d/rc6.d/S01reboot /etc/sysconfig/init /etc/sysconfig/netconsole /etc/sysconfig/network-scripts/ifcfg-lo /etc/sysconfig/readonly-root /etc/sysctl.conf

Being moved out of the way would be seen as a change to a config file. =)

Thanks Tom!

-edited-

It turns out I picked on a sym link (/etc/rc.local points to /etc/rc.d/rc.local). I picked on that one because I saw it within the output of "rpm -ql initscripts".

That makes sense - thanks again!

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.