> > The implications for NFS are interesting. What happens when you NFS
> > mount a volume that has files owned by UID's that are part of the
> > array of root uid's. Bingo! They get root access! (or at best get
> > root access when the root uid changes to equal theirs) From then
> > onwards, they have total power, and can read and write as uid 0, and
> > also get their UID remapped to root_uid when the uid changes.
>
> Not quite. Because only one of the uids in the array would have been
> considered root at a given time. And of coarse, no normal user would have
> been given one of these uids.
I know only one at a time is root. Its just that say I have uid 306
on the nfs server (which might be one of your array of root uids on
your linux box). I also have an account on your linux box. I can
crack root by starting a process on the linux box that just sits and
waits until root_uid == 306, and then does its nasty stuff.
>
> The main exploit I was aiming to disable was as a matter of fact an nfs
> expoit. And I was planning to disallow root access over nfs unless a given
> user had the right uid.
The only thing is that it'll be hard for you to choose 500 uids and
disable them over nfs without breaking a lot of sites NFS setups. or
disable one at a time and explain to that user why he can't get to his
home directory.
>
> It would have been fun, but I've learned from some replys that this would
> have not been a good idea to start with.
>
> >
> > You still have to have uid 0 being root as well, or you break just
> > about every binary that runs as root, but changes its euid to
> > drop/raise privaleges (a lot of daemons do this). You'll also break
> > the security of a lot of stuff that checks to make sure its not uid 0
> > before running. It could now run insecurely as root_uid without
> > really knowing.
>
> Well, the point of this would have been for the system to keep the special
> uid transparent to the application layer. As most of the access control is
> beeing done by the kernel anyway.
OK, but how do you stop binaries from doing this sort of thing:
if (euid == 0) {
...drop privs
}
Do you map the current root_uid to zero in calls to get/seteuid etc?
> > The whole thing seems extremely ill-concieved and astoundingly
> > foolish. Based on what the poster has shown here, he has no real
> > understanding of unix security at all. If he insists on writing this,
> > I only hope his tutors know more about unix than he does.
>
> Hmm, the point of writting this mail was to get some feedback from
> hardcore kackers. While I will not insist on writting this, I still
> beleive that it could have been done in a secure way (anyway, what is so
> special about the number 0).
Nothing is special about 0 except that it is special. The thing about
root and uid 0 is that you know its special and all-powerful, so you
take steps to protect it. Its much more difficult to protect a moving
target.
> Maybe I don't know everything about UNIX security, but I guess we all have
> to start somewhere. While I have been using UNIX/Linux for a few years and
> don't consider myself a beginner or an expert, I do know enough about OSs
> and C programming to do something usefull for Linux.
That's true. The problem is that if you think "I don't know why
noone's ever thought of this before" that should be a bit of a warning
sign. Some pretty clever people have worked on unix over the last
twenty years or so, and its just possible that some of them will have
seen the pitfalls of your new idea (whatever it is). On the other
hand if you're sure you've got a good idea you could try to prove us
all wrong.
A good place to start for a linux project might be to port something
that they have in another unix to linux. For example I think openBSD
(it might be one of the others) has a lot of security features that
might be interesting to port, including random pids. When a process
starts up it doesn't have a sequential process id, it just gets a
random number. This makes stuff like /tmp races much less likely. Its
also a project of (probably) manageable size. We generate
high-quality random numbers in the kernel already. You're just going
to add a fixed overhead to process startup because you'll have to look
up in a hash to see if that pid is already taken or something. You'll
also have to clear the pid hash entry when the process dies.
> As it is impossible to know everything in computer sciences, I don't think
> it is appropriate to insult people like this. I am learning from these
> replys, and maybe in a few years I hope to be some help to some, or maybe
> just one of you. Untill then, I beleive that it is possible to point to
> some weaknesses without insulting me so bad. Unless, of coarse, you've
> been born with your UNIX skills, remember that you are just an
> ex-beginner/intermidiate/good/very good/etc UNIX user.
Sorry. There's a difference between criticising your idea and
criticising you. I certainly never meant to insult you. Part of the
problem was that I didn't think you had given the full implications of
your idea a whole lot of thought. I also misunderstood the tone of
your original mail, and thought you were saying your stuff was a
masterpiece (which got me a little riled)
I hope this initial onslaught hasn't put you off kernel hacking
entirely. There's a whole lot of people cleverer than me on the list,
and I'm sure someone can suggest a great project for you. If you mail
me privately, I'll be happy to give you a load of references to get
you started.
Sean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/