What's the noautologin / secure default password when /etc/shadow fails to save?

[baz]

I tried enabling a password by supplying the boot codes "secure" and "noautologin". This prompted me to create a root pass and a user pass. Then I added /etc/shadow to .filetool.lst so that my password could be saved (per another post). I then tried locking my screen using xlock, but it would not accept my password, so I had to hard reboot - which means my /etc/shadow didn't save either. When I got back to the login screen it wouldn't accept my password.

All this to ask, what's the default password to get in?

[gerald_clark]

There is none.
Boot with the noautologin and secure options again.

[baz]

Ah ok.

As a side-note, "secure" should really be renamed "changepassword" to emphasize the temporary nature of that boot code.

Also, this whole setup is not secure at all if anyone can simply remove the noautologin boot code to gain access to an account. What do people think of that?

[danielibarnes]

Also, this whole setup is not secure at all if anyone can simply remove the noautologin boot code to gain access to an account. What do people think of that?

I don't know if you are aware, but any linux system which allows you to modify boot parameters is insecure in the very same way. The 'single' option will boot a system to a root shell with complete access to the system. I use this from time to time when I forget a root password.

Even if you were to prevent the modification of the boot parameters on the normal boot media, it is a simple matter to boot grub from a floppy, cd, usb drive, or PXE where the parameters may be modified. If you were to configure the BIOS to disable all other boot methods and password-protect it, you'd still have to worry about BIOS master passwords or clearing of the CMOS.

In short, if you have physical access to the system, you can get complete control of it. It's just a matter of how difficult it is. It is more accurate to think of the "secure" boot parameter as providing secure remote access.

[baz]

Good points. What about an encrypted home? That would be safe from hardware tampering but then you could simply autologin?

[baz]

I just can't get this to work, it never wants to accept my password. Should/can I delete /etc/shadow to really start over? I think there is a fundamental flaw in the whole thing related to the fact that I am using a custom user. When I try logging in as myself or root I keep getting incorrect password, but if I simply type "TC" I GET FULL ACCESS TO THE SYSTEM!!!

[danielibarnes]

I see. I did some quick investigation. I don't know why, but xlock doesn't use the user's password. The first time you run it, it prompts you to enter a "Key." It then stores that password in ~/.xlockrc for validation. If you remove that file, it will ask you to enter a password again the next time you run it.

If I run xlock as root, it does not prompt for a "Key" and correctly uses the root password to unlock. Does anyone know why it would not work for the tc user or how to make it work?

[baz]

danielibarnes, I noticed that too but then found xscreensaver in the repo - it's much better in all ways.

[danielibarnes]

The man page states:

Shadow Passwords
If the machine is using a shadow password system, then xlock may not be set up to get the real password and so must be given one of its own. This can be either on the command line, via the -cpasswd option, or in the file $HOME/.xlockrc, with the first taking precedence. In both cases an encrypted password is expected. If neither is given, then xlock will prompt for a password and will use that, also storing an encrypted version of it in $HOME/.xlockrc for future use.

It seems to say xlock cannot use a non-root user's password in systems which use shadow passwords. I didn't notice it before, but the .info points this out. xscreensaver-base has a number of dependencies, but xtrlock-2.0, xlockmore, and xautolock-2.2 do not have any. Lots of choices.

I never tried encrypted home, so I am unfamiliar with its operation. It can secure your data, but the system itself would still be just as open.

[curaga]

cryptohome is not supported in current releases anymore.

[OldAdamUser2]

Bcrypt is built into TC base (at least that seems to be the case). You might find that it can handle your file encryption needs. It seems to provide very secure encryption for individual files. Folders or groups of files could first be zipped and then encrypted.

Maybe that will meet your needs for greater security. It does for me. Here is a link to the manual page for more info.

http://linux.die.net/man/1/bcrypt