Onward branch

Robert Connolly robert at linuxfromscratch.org
Sun Oct 19 11:16:05 PDT 2008

On Sunday October 19 2008 11:57:47 am Kevin Day wrote:
> There are some problems I noticed, some applications like tar will
> overwrite the set sticky-bit group with one of its own choice
> (normally the group of the user extracting the file).

Have you tried 'tar -p'?

> Also, are you going to put the list of groups, permissions, and init
> script requirements on a list somewhere such as the wiki or a text
> file in your onward directory?

Yes, probably both.

> > Also, if it's possible, straight off the reboot, I want agetty to run as
> > non-root. Maybe not today, but it's something to keep in mind. The
> > rebooted temporary system should be 100% hardened. This can be done in
> > the boot scripts with execcap and/or Debian's runas program.
> I am pretty sure the agetty user would have to be able to read the
> /etc/shadow (actually, how about /tools/etc/shadow ?)
> So, is it possible to make a shadow group and put the agetty user with
> read permissions?
> This would then leave how the agetty user would switch over to the new
> user.

There's no shadow file on the first boot. I suggest key authentication if 
logging in from network.

For the finished system, the agetty user would need group read permission 
on /etc/shadow. /etc/shadow could still be owned by root (or something else). 
cage, expiry, and chfn, could probably lose their CAP_DAC_READ_SEARCH 
capability if they're sgid to the shadow group.

The sshd process that normally runs as root could also run as a regular user, 
but would need CAP_DAC_READ_SEARCH to read keys in user directories. This 
capability would also let it read /etc/shadow, so it wouldn't need to be in 
the shadow group.

Agetty and sshd would need CAP_SETUID/CAP_SETGID, and maybe 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/hlfs-dev/attachments/20081019/3ee2018c/attachment.sig>

More information about the hlfs-dev mailing list