[Yum] Security issues with include= implementation in yum.conf

[James Olin Oden]

On Sat, 4 Oct 2003, seth vidal wrote:

> > After looking at this I have few suggestions. 
> > 	
> > 	1) Allow the user to disable the newtwork includes.
> 
> How? The includes are to be used to specify the config file - the only
> place to set them would be on the command line. And even then you'd
> probably not have a functional config file at all.
>
Oh.  I misunderstood and assumed that they existed in the config
file itself, the whole thing being started from the config on the 
system. 
 
> > 	2) Have do not allow network includes to override already 
> >  	   configured global items.
> 
> It wouldn't have to override them - it would just have to add a
> repository that had newer packages than you do or than the other repos
> do.
>
Again, my assumption was that the includes where occuring in the 
the config file itself.  I must have completely misunderstood the 
feature.  I have a config format for building RH distros that supports
includes (but not from the network), so I was thinking along those
lines.  My bad...sorry.
 
> > 	3) Perhaps have certain items that cannot be set (or unset)
> > 	   via a network include.
> 
> I think that would be a mess both programmatically and from a user
> perspective.
> 
The only one I would really see doing is the disabling of gpg signatures,
as far as it being a mess programatically, it depends on how your parser
is written.  I haven't looked at it so I can't say.  But just 
hypothetically if your parser handled includes by recursively calling 
itself again with the path/URL to the include then when the parser is
re-enterd it knows whether it is picking something up with a URL as 
opposed to a filesystem path.  Knowing this it can easily without too
much convolutions make a decision of whether a particular config item
should be parsed in said context.  Even if it is not recursive, when it 
begins parsing the new file (i.e. the include) it could simply set a 
state variable depending on whether it was using the include off the 
net or the filesystem, and then, as above intelligent decisions can 
be made about the validaty of particular config items based on the state
of the parser (i.e. is now parsing a config from the net, or from the
filesystem).  It is a little more involved with that, but I am sure 
you get the picture.  

Ulitimately, as with having the gpg sig checking disabled from a config
over the net, I was only trying to point out that there may be some
config items that are best not overridable by configs from a remote
source that you don't have control over.

> 
> > I think would go a long way towards making it more secure in a network
> > environment.
> > 
> > Cheers...james
> > 
> > P.S. The gpg signing did come to mind, but now I am in fear of saying it
> > (-;
> 
> The problem with gpg signing the config file snippets is this:
> 
> 1. you'd have to use gpg to check them
> 2. you'd have to have configured a place to store the gpg keyring - b/c
> we're checking text files, not rpms at that point.
> 3. where would you look to find the configuration data to know where the
> gpg keyring is stored?
> 
> At that point it starts being highly questionable as to whether or not
> to have this feature at all, b/c at that point running yum as a user
> would be almost impossible depending on where the gpg keyring is stored.
>
I understood all that thus the (-;.  I was only joking that it poped into
my head as it must have yours or you wouldn't have mentioned it.  Yes,
security is about a lot more than algorthims, especially when you have
to consider things like collusion, social engineering, physical security
and other annoyances from the real world.

Cheers...james 
> -sv
> 
> 
> _______________________________________________
> Yum mailing list
> Yum at lists.dulug.duke.edu
> https://lists.dulug.duke.edu/mailman/listinfo/yum
>