[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Exim permissions



On Sun, Dec 01, 2002 at 09:49:52PM +0000, Clive Standbridge wrote:
> On Sat 30 Nov 2002 17:14:09 +0000(+0000), Pigeon wrote:
> > 
> > I've been writing a C program to burst incoming digests into separate
> > messages.
> 
> Did you know that procmail can regurgitate digested mail? From the procmailex man page:
> 
>        Split  up  incoming  digests from the surfing mailing list
>        into their individual messages, and store them into  surf­
>        ing, using surfing.lock as the locallockfile.
> 
>               :0:
>               * ^Subject:.*surfing.*Digest
>               | formail +1 -ds >>surfing
> 
> I hope this helps.

Well, I've learnt a whole lot more about exim and how email works, and
I've also discovered that Linux doesn't try and stop two processes
writing to the same file at once. (Which makes sense, really, though
it looks like it doesn't.) And I know more than before about uids and
gids. And there's the satisfaction of having written An Email Handling
Program, even if the stuff it actually does is dead simple. So if
you'd told me two days ago, look what I'd have missed out on...

Thanks, anyway!

On Sun, Dec 01, 2002 at 03:52:35PM -0600, Shyamal Prasad wrote:
>     "Pigeon" == jah pigeon <Pigeon> writes:
> 
>     >> Better still, use sudo and you will not have to do any C
>     >> programming :-)
> 
>     Pigeon> Even for your set real u/gid trick? - given that there's
>     Pigeon> no setgid(1), and setuid(1) doesn't let you set the gid as
>     Pigeon> well? And it can manage that without being a security
>     Pigeon> hole? That's pretty neat.
> 
> Yes, sudo should work. That is because sudo actually runs the program
> as root, not with the effective user id of root.
> 
> You might find it instructive to modify your little C program to run
> "/usr/bin/id" instead of exim and see what it prints out with
> different combinations of setuid/setgid file permissons and sudo.

Yeah, I think I'll do that. It would indeed be instructive.

> You did mean setuid(2) up there, right? There is a setgid(2) call.

No, I know there's both a setuid(2) and setgid(2), cos I used them as
per your suggestion earlier. I did mean setuid(1); man doesn't say
anything about how this affects group as opposed to user ids, so I
presume it refers to /etc/passwd, and a little experiment with passing
it a uid:gid pair showed that it doesn't understand that format.

However, on re-reading what I wrote, I can't work out what I was
trying to convey in that paragraph, so please ignore it and I
apologise for wittering.

> I have not heard that sudo is inherently insecure in any specific way
> (but I'm not a long time sudo user).

I think it's a complexity issue. The sudo binary is about ten times
the size of that of my one-line C program, and has far, far greater
complexity, as well as allowing the user to, in principle, run _any_
command as root. So it must offer many more points of attack. If I was
to start writing more complex setuid-root programs to do a greater
variety of things than just run one very specific command, it wouldn't
take very long before the situation reversed.

About 15 years ago I discovered that since uux 'sudo's and runs things
as root or some privileged admin user, I could bounce uux calls around
and get myself a root shell. Setting up sudo to allow user pigeon to
run some complex app as root might open up a similar hole. I think
it's a pretty remote possibility, but it must exist.

On Sun, Dec 01, 2002 at 08:13:24PM -0500, Derrick 'dman' Hudson wrote:
> On Sun, Dec 01, 2002 at 10:02:56PM +0000, Pigeon wrote:
> 
> | OK, but I still don't quite understand why the "trusted user" bit
> | doesn't work.
> 
> Oh, yeah, I forgot to mention that part.  The short answer is
> trusted_user doesn't mean what you think it means.  See section 5.2 of
> the spec for a longer explanation.  The main thing I remember is that
> a trusted user is allowed to specify an arbitrary envelope sender
> using the -f command line option.

That's how I originally intended burster to deliver the messages to my
mailbox - by feeding them to exim to send to pigeon, using the -f
option so they still "came from" the digest rather than pigeon@pigeon.
It worked when I piped a digest into burster from the command line,
but not when burster ran automatically from the Exim filter. I
couldn't answer an exam question on it, but I'm beginning to get a
feel for why this is, now.

> All a man's ways seem innocent to him,
> but motives are weighed by the Lord.
>         Proverbs 16:2

I like your choice of favourite verses, too.

Pigeon



Reply to: