Brian Utterback wrote:
> 
> 
> Darren J Moffat wrote:
> 
>> I'd like to hear from other ARC members on this but I feel that 
>> introducing a root package just for updating exec_attr is wasteful, 
>> even though it does mean putbacks to two consolidations.
>>
> 
> So, do I take the lack of further comment as assent? Is the plan to 
> simply add a line to exec_attr and forgo the *r package?

That is my strong preference but it seems no other ARC members are 
either listening or have an opinion on this that they wish to share.

> By the way, does that have any ramifications for possible name 
> collisions? If as a nefarious evil genius bent on world domination, if I 
> wrote a FOSS package that happens to install (amongst other items) a 
> binary called "/usr/sbin/ngrep" that installs a rootkit when run as 
> root, would that amount to priv elevation if run by the network admin?

Yes it would but that is in no way prevented by splitting the 
installation of this projects components over two packages.

But then if you can get someone to install a package with a trojan horse 
ngrep why bother with exec_attr entries just make the trojan ngrep 
setuid, or even why bother with that you may was well just install the 
rootkit straight out of the package.

> I guess I am asking if there is an issue with decoupling the exec_attr 
> line from the actual binary installation?

No, and in many cases delivered by ON there are entries in the exec_attr 
file when the corresponding packages that deliver those binaries are not 
present.

Also remember that your exec_attr table might not be local or even 
hosted on the same OS release so we already have that situation anyway.

-- 
Darren J Moffat

Reply via email to