Hey mundoalem, > "4.3. Adding the LFS User" > http://www.linuxfromscratch.org/lfs/view/stable/chapter04/addinguser.html > > is lacking of notes on security issues about the creation > of the "lfs" user and "lfs" group. I know the book just can't > cover every aspect of security problems and errors it might > occur if you do the things the book tells you to do. > The sysadm should know what he is typing.
I agree, the sysadm *should* know what he is typing! But sometimes he doesn't. The book isn't exactly lacking security notes but assumes an understanding of *nix user security. > However, IMHO it would be good to just have a box remembering > the sysadm that as he creates the "lfs" user and group he > may be exposing some security gaps that may be exploited. So > he should see if the user "lfs" could lead his host services into danger. I'm no official word but here's my take on your concern. Adding the lfs user shouldn't be any less secure than adding a regular user to your system. If you are truly concerned you can skip the passwd portion of the 'Adding the LFS User' - lfs can't even log in. Only a superuser can 'su - lfs' to get to a working prompt. > My suggestion is: > > "Notice that the user and group just created in this section could > compromise the security of the host system. If any service running > on your host system could be exploited by means of an user account > you should be careful and configure the service to deny access to the > "lfs" user and group. For example, if you run OpenSSH put the "lfs" > configure it to dny access to "lfs" user and group (please refer to the > OpenSSH documentation)." I think this is getting a bit case-specific. If someone is running sshd I would hope they understand how to control it. Same goes for a system running a standard PAM as another example. I'm not trying to shoot your idea down, I just think it could be precise. For example, this is the current section that explains setting the lfs password: > To log in as lfs (as opposed to switching to user lfs when logged in as root, which does > not require the lfs user to have a password), give lfs a password: > > passwd lfs Could have the wording reflect your security concerns: > The book will be using 'su - lfs' to switch to the user lfs when logged in as root. This > process does not require you to give the user lfs a password. > If you want to allow regular system access to lfs (such as login, ssh, etc), give > lfs a password: > > passwd lfs > > Note that in the case of remote access via a network, it's probably in your best interest > to use a strong password. This is true for any user with network access including > the one created above. ... maybe? Just a thought. There are too many variables to the host system concerning potential access. Adding an openssh specific note to the lfs instructions doesn't really imply increased security for other forms of access, hence the all or nothing approach. Personally even after thinking about the wording I think for most linux users the current wording is fine. But I'm not really sure how to classify easy from hard in this OS anymore. Jonathan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
