root vs user. installing firefox

Agathoklis D. Hatzimanikas a.hatzim at gmail.com
Sat Dec 20 23:03:44 PST 2008


On Sun, Dec 21, at 01:23 Simon Geard wrote:
> On Sat, 2008-12-20 at 11:29 -0600, Bruce Dubbs wrote:
> > Simon Geard wrote:
> > 
> > > That said, I don't always follow that advice - my scripted builds run
> > > entirely as root, since having a script acquire root permissions partway
> > > through is a pain
> > 
> > Just set up sudo to run without a password:
> >    User_Alias  ADMIN = <userid>
> >    ADMIN       ALL = NOPASSWD: ALL
> 
> I do make use of sudo, but using it in the scripted build represents a
> catch-22 - it's the scripted build which installs it. I know I could
> work around that, but it's mostly a case of can't be bothered.
> 
> Besides, I don't really like configuring sudo to not need a password,
> even if I narrow it down to very specific commands. From experience,
> it's too hard to configure safely - I can obtain root shells on most of
> the servers at work by exploiting subtle sudo weaknesses, and I don't
> want to reproduce that on my own machine. I mostly use it as a more
> convenient syntax of 'su -c', requiring the root password rather than a
> user password to do anything.
>

I agree Simon, thanks.

Using sudo without a password should be discouraged at any chance and
should be avoided.
Unfortunately there is a relative line in the shipped sudoers and I am 
thinking that maybe it will be wise to eliminate it with a sed (anyone
cares to open a ticket?, I have a bad reputation in blfs dev team,
regarding this issue, thus I can't do it myself), so it won't be exposed
anymore.

By the way, does Ubuntu use sudo without password? I am not sure.
But we bought a netbook acer aspire one for our son, that is running a
crippled fedora release and they do exactly that. So maybe this looks
that it will become a trend.

On Sun, Dec 21, at 01:41 Ken Moffat wrote:
>  I'm still having trouble understanding why people think sudo is
> safer, even where it is configured to require a password (I accept
> that restricting it to specific commands is safer, but probably
> inconvenient in BLFS).  In OSX I have to type my user password the
> first time I sudo, but then ISTR I can continue to sudo for a period
> of time without repeating the password.

This can be done by increasing the default timeout which is by default
5 minutes.
In fact this is one way to avoid to retype a password in a scripted build
(of course can be reverted afterwards back to its default, or to 0 to
always prompt for a password), by setting a reasonable 
'timestamp_timeout'.

Another way to increase a bit the security while use sudo, is to use the
root password instead of the user password; this is achievable by setting
in sudoers:

    Defaults   rootpw

but I am sure that is not always feasible in corporate environments.

Now there is a way to use sudo in a scripted builded without using a
password and without touching the sudoers file at all and it can be a
little bit more safe, if use the following with care.

Sudo accepts a password from standard input, using the -S switch, like
this.

========================================================================
[08:21:37][/tmp][0]> whoami
ag
[08:21:58][/tmp][0]> echo "password" > secretfile
[08:22:07][/tmp][0]> touch /root/temp
touch: cannot touch `/root/temp': Permission denied
[08:22:13][/tmp][1]> cat secretfile |sudo -S touch /root/temp
[08:22:20][/tmp][0]> cat secretfile |sudo -S ls /root/
temp
[08:22:35][/tmp][0]> rm -v /root/temp
rm: cannot remove `/root/temp': Permission denied
[08:22:39][/tmp][1]> cat secretfile |sudo -S rm -v /root/temp
removed `/root/temp'
========================================================================

But now we have a file with the password in the filesystem. One way to
decrease a bit the security risk is to store that file in a tmpfs
filesystem, for example in /dev/shm, so after a reboot this file will
be remove it.

But there is another way to avoid all this risk, to make it (I believe)
impossible to anyone hack your machine. :)

Here is a way. We'll use the vim encryption capability, see more within vim
in:
   
    :help :X

Assuming you have vim installed which is installed by default in lfs.

========================================================================
[08:28:29][/dev/shm][0]> pwd
/dev/shm
[08:28:44][/dev/shm][0]> vim secretfile
========================================================================

Now while in vim, type the password in the first line, save the file
and then use from commandline:

    :X

it will prompt for a password - 
but before do that, run a md5sum in a file in your filesystem that there
is no way to be modified while you run the build -
When you are done with typing the password twice, save the file and exit
from vim.
Now you have an encrypted file in a tmpfs filessystem with the stored
password. But it can't be read.

========================================================================
[08:45:49][/dev/shm][0]> cat secre*
VimCrypt~01!xh0Eي·¡/
========================================================================

But, there is a way to export with vim the password from the secretfile
and write it in another temp file that can be deleted after the completion
of the command that uses sudo; or it can be deleted when you are done with
a package, or when you are done with the build, depends on how paranoid you
are.


Here is how:

========================================================================
[08:49:40]][/dev/shm][0]> vim -u NONE --noplugins --cmd  \
"let &key = split(system('md5sum /path/to/somefile/that/you/run/themd5sum'))[0]" \
-c "let pass = [getline(1)]" -c "call writefile(pass, '/dev/shm/pass')" \
-c ":q!" secretfile

[08:31:22][/dev/shm][0]> cat pass
password
========================================================================

Then just use the sudo with the -S switch to read from that temp file; in
that case is /dev/shm/pass.


Use at your own risk.

Regards,
Ag.




More information about the blfs-support mailing list