[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070402005653.GB6610@openwall.com>
Date: Mon, 2 Apr 2007 04:56:53 +0400
From: Solar Designer <solar@...nwall.com>
To: owl-users@...ts.openwall.com
Subject: Re: Owl-based desktop environment
Grigoriy,
On Sun, Apr 01, 2007 at 06:04:08PM +0400, Grigoriy Strokin wrote:
> 1) Which RPM set with a wide range of useful applications
> should I use?
> I tried downloading Fedora Core 6 i386 RPMs, but they require
> GLIBC-2.4. Then I tried
> rpm --replacefiles --nodeps -U glibc-2.5-3.i386.rpm
> but then PAM modules stopped working and it was even impossible to
> login. So I downgraded to libc-2.3.6.so.
Right - "upgrading" glibc on Owl to that from another distribution is
really not a good idea. We have our new password hashing framework
introduced in our glibc, and our tcb suite makes use of that. That's not
to mention that we have lots of security hardening patches in glibc.
> Should I use RPMs from older versions of Fedora?
Yes - Dmitry has already explained that you should be able to use most
RPMs from RHEL4 and FC3, as well as some from FC4.
However, Red Hat's packages of X and related stuff have too many
dependencies that you might not want to bring in (Qt, Kerberos). If so,
you might pick their SRPMs and rebuild from source with minor tweaks to
avoid the dependencies. If you do that, then SRPMs from a later version
of Fedora will likely work.
Also, please see Owl/doc/REDHAT for some known issues.
> 2) What is the best way to install X.org? Again, I thought
> about downloading all Fedora RPMs with names starting from
> xorg-x11-*, but they do not form a complete set:
> there is xterm-*, which doesn't start with xorg-x11-*.
Yes, you'd have to download more and more of their packages until you
have all of the dependencies satisfied. I can provide you with working
minimal lists of X-related packages from Fedora as of two years ago,
assuming that you go for the rebuilds (otherwise the lists would be much
longer... but you might actually save time by just installing stuff
rather than rebuilding, so it's up to you).
> In the epoch of XFree, there was a single file
> x.src.tar.gz, which you extract and type 'configure && make',
> but there is no such a file for X.org...
It should still be possible to build X from source if you like. It's
just that you might find it convenient to have all of this stuff RPM'ed.
> 3) Later I used sudo, but now I know it is not a good idea
> to use su/sudo to root as a non-privileged user.
> So, what is the right way to get admin's privileges while working
> locally in X Window as grg?
I don't think there's one "right way". I'm not aware of a perfect one.
Well, maybe if the X server or the kernel had a SAK (Secure Attention
Key) that would not involve switching the display to text mode - that
would be the right thing to use. OK, the use of a same-resolution
framebuffer should help avoid the flicker, and it might not be bad on an
LCD anyway. You could also run two X servers at the same resolution,
but in my experience switching between them can sometimes result in
glitches.
If you need to do things as root very often, then I'm afraid that you'll
have to use "su -" despite of its risks. However, you may mitigate
those risks by doing some of your work as a non-root account other than
the one that you "su -" from. Say, you "exec startx" as user "grg-x".
Then, once in an xterm, you "su - grg" for accessing your e-mail
(parsing untrusted data obtained from the remote). However, you "su -"
(to become root) in another xterm from "grg-x", not from "grg". You can
even have the same password set on root and "grg", it does not really
matter as long as you type in both passwords frequently enough anyway.
One problem with the above approach is that it's not very effective for
X apps (those that speak X protocol to your X server). Even if you run
such an application as "grg" while su'ing to root from "grg-x" only, the
application will be able to intercept your root password (and do other
nasties) via X protocol features. So you should make sure that account
"grg", that you run non-X-enabled Mutt from (for example), is not only
not used to speak to the X server, but also has no privilege to do so
(no access to the X server socket or to a current .Xauthority file).
For real X apps, you may use a third non-root account and have them
speak to your X server via a filtering X protocol proxy:
http://cons.home.cern.ch/cons/mxconns/
I've never tried this last thing out, so I'd appreciate your comments if
you do.
> ssh r_grg@...alhost ?
As others have pointed out, this is the same as "su - r_grg" from a
security standpoint.
However, for moving or copying files between differently-privileged
accounts on your system, the use of "scp" may be safer than plain "mv"
or "cp". Yes, I am often using "scp myotheraccount@0:filename ." or
the like. "@0" is shorter to type than "@localhost". :-) It is
important to always initiate the "scp" from the more-privileged account
whenever that distinction can be made. (You don't want someone having
compromised your less-privileged account to intercept your password for
your more privileged account.) So with the above examples, if you want
to copy a file between users "grg-x" and "grg" (in either direction),
you'd run "scp" as "grg-x", not as "grg".
> What about using passwords?
I don't understand this question - it is too generic, while you probably
wanted to ask something more specific.
--
Alexander Peslyak <solar at openwall.com>
GPG key ID: 5B341F15 fp: B3FB 63F4 D7A3 BCCC 6F6E FC55 A2FC 027C 5B34 1F15
http://www.openwall.com - bringing security into open computing environments
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
