Why don't we make one ebuild that when emerged will make sure that you have all of the newest security fixes on your box - while not making you rebuild everything.

I would think this would be pretty easy to do. For instance for the recently released tomcat security issues all we would have to do is put a dependency in an ebuild with tomcat >= tomcat-4.0.5 . Then when that ebuild gets emerged it would automatically make sure that tomcat would get emerged.

I think we could call this ebuild "security" - for no other reason than it would be fun to run:

emerge security

Why is this needed you ask?? Well, take my home desktop for instance. I like the way it runs now - I like the versions of all the apps I have now. I don't want to risk running an "emerge -u world" every week/night. At the same time there is no better way to get all the security updates needed for my machine - besides going back through the GLSA's and other security postings on the net and emerging each and every one of these apps.

This ebuild would be meant to be used in a cronjob - probably run nightly or weekly depending on the workload of the machine.

What do you guys think? Good idea? Bad idea? I am willing to spend some time creating a mockup of one if people are interested.

*shrug* I just emerge the security-fixed package. Usually the GLSAs aren't relevant to my system. I'd think an ebuild for security would just add an unnecessary step.

Package X has a security problem. A developer has to make a new ebuild for the fix, and then update the 'security' ebuild. Seems redundant to me._________________lolgov. 'cause where we're going, you don't have civil liberties.

I guess the point is that not everyone knows that a security-fixed package has come out.

If you miss the GLSA or some other security announcement - how are you to know???

If we have one ebuild that will make sure your computer is up-to-date as far as security goes then it doesn't require any hunting on the admin's part - and can be done automatically through a cronjob.

Redundant? I dont know. Any packages that are security sensitive (especially the ones that provide external services) should have maintainers that are aware that people depend on those packages being secure - and those maintainers shouldn't have a problem with updating ONE line in a security ebuild - to make sure that all the users of their previous work are protected.

Kanus - not everyone has the time, nor the ambition to lurk on this board the way some of us do. Lots of people never read securityfocus - or even visit slashdot on a weekly basis. It is for these people (and the admins that want to automate stuff) that I think this is a good idea.

Even if maintainers aren't willing to update a security ebuild - other people could do it - in fact I would be willing to do a lot of it - but I, like others, do not stay completely up with the security scene, so I might not be the right person.

I like it from a theoretical user standpoint. When I start to think about the practicality, I get a little confused. If you just have a big "security" ebuild like "kde" or "gnome", that contains updates to every single package that has had a security-related bugfix, wouldn't "emerge security" install a zillion applications that people didn't have installed before? If I did "emerge security" as in your example, wouldn't I get tomcat 4.0.5 whether I used tomcat or not?

There's also the issue that some packages have to get recompiled after libraries have changed (like openssl/mod_ssl recently), and the one that choice of USE flags or architecture could affect whether there was really an issue. This is less of a big deal, because the only risk would be installing an upgrade that wasn't really needed.

So I'm not really seeing how this could be implemented._________________For every higher wall, there is a taller ladder

I guess the point is that not everyone knows that a security-fixed package has come out.

If you miss the GLSA or some other security announcement - how are you to know???

Any sysadmin worth paying would subscribe to the relevant mailing lists for the OS they use. Any GLSAs that are posted in the News & Announcements forum come from the mailing list. Mailing lists for Gentoo can be found here. The page lists a 'security' mailing list, but I'm not sure exactly what that has on it. 'gentoo-announce' has GLSAs on it. So far, I have only seen important information come across on announce. On the off chance I don't check my email, I have my home page set to this . I update it once a month to load the current month's archives.

Quote:

If we have one ebuild that will make sure your computer is up-to-date as far as security goes then it doesn't require any hunting on the admin's part

I always thought security was part of the admin's job. I also would expect that most admins want to know what is being done rather than a cronjob auto update critical servers.

Quote:

Kanus - not everyone has the time, nor the ambition to lurk on this board the way some of us do.

I agree completely. That is why mailing lists and their archives exist. Especially in regards to security. The forums wouldn't be my first resource if my sole purpose was security related.

I'm not opposed to the package existing._________________lolgov. 'cause where we're going, you don't have civil liberties.

Glad you posted. I have been reading over the portage docs myself trying to come up with a solution to the problem you pose (The one about emerging stuff you never had before).

On a less fine grained measure we can use the USE variables to rule out security upgrades (such as if gnome is not in your use variable you wouldn't get the gnome updates). But this is not the best solution because things like tomcat don't have a USE variable.

Does anyone know if there is a way to query whether or not a package is installed in portage??? There has to be a way because people do it with kportagemaster and the like.

I dont want to emerge a bunch of stuff people dont need. The whole point of this script is to keep that from happening. I want it to just update software you have on your system and not bother anything else.

Anyone with ideas??

kanuslupus:
I completely agree with everything you said. The problem is not everyone is, or has, a system admin. A lot of people use gentoo as their home desktop machine, and don't even think about looking for security upgrades.

I personally dont subscribe to the gentoo mailing lists because I already have enough inbox clutter (indeed that is the reason I am on this forum so often) - I am sure that there are many like me.

I know it is hard to believe (it is for me!) - but some people just USE their machines without too much thought as to what the OS "needs".

i think its better to have the the developers update the package.mask file to only allow the patched "secure" versions. This is what they've been doing all along. just emerge rsync regularly and keep an eye out for security related updates.

perhaps if rsync outputted some message like "it is now recommended that you updated the following packages for security purposes" and listed them?

Why not implement this as a class like "world" and "system"? that way sysadmin's could tweak /var/cache/edb/security to whatever they want and then do something like "emerge -u security".

In the security class would be things like daemon's, servers, etc (openssh comes to mind or maybe this tomcat thing mentioned above (dunno what that is though)). I guess i'm implying that security holes in something like gnome are not as serious as ones in openssh; but to be honestly, i think thats a bit of a fallacy.

I believe there are automatic security updates in debian, so it can't be a really bad idea .

A sysadmin should check mailing lists, but many here are 'only' users wanting a bit of security, so automatic updates can be worthwile.

Personally I prefer 'bloody bastard's idea, doing an 'emerge -u security'.
To reduce stress on the rsync servers, a special 'emerge securitysync' could be made, only rsyncing a subset of the packages. Then you could run both commands in a daily cronjob (without flooring the servers).

Ive also been missing a similar option with emerge. In fact, I was about to post a question about this right now - but decided to have a look-see if someone else had similar needs. Maybe its even possible to have a cron job running "emerge security" on servers left unmaintained for longer periods

For me, I receive Gentoo security update emails on my workstation. Then I update my system, of course. But sometime Im on one of the other Gentoo boxes I have, and I remember this security update and I go like "hmmm, what was it called again" Of course I could just ssh in and check the mail on my workstation, or just open a webbrowser and read up on the mailinglists. But for me it would be more elegant to do a "emerge rsync" and then "emerge security" and let the system know on its own what to do.

Another example why such a feature would be nice, is those of us using computers with slow CPUs. I have Gentoo on my laptop, and doing an "emerge rsync" and "emerge -u system/world" would almost always install alot more than just security updates.

Off topic perhaps:
IMHO, it is of no use that we mortal users (no offence to those of your who really have your feets into the gentoo emerge code) discuss how this could be done. Every emerge developer knows or can discuss among themselves how this can be solved most elegantly. What is important on the other hand, is that users have brainstorms around new features, and say "OK, this would be a nice feature which Id really appreciate" and then the developers can look at the options on how to implementing them.

But bottom line is: Yes, Id really like a "emerge security" option which would bring my system up-to-date security wise.

What you obviously are trying to do, is to tell security related updates from non-security related updates. This could be achieved by looking for "security" in the latest entry of the respective ChangeLog, when doing
"emerge -up world".

Write these to a list, update them, and you're done.
Or did I miss something?

I personally like the idea. Although it may create an extra bit of work for the developers, I believe it would be a great service for the gentoo comunity. Many of us have more than one gentoo box, some of us have several. Keeping up with security patches for all the different boxen could prove to be a pain. None of us want gentoo to become a pain to do upkeep on. IMHO adding an app (would it take a seperate app) would make gentoo far more robust and that much more likely to placed in more environments where it's sure to get noticed.

I like the idea of having a emerge world --security (i.e. marking some ebuilds with a security flag so that they can be the only ones updated).

I know the 'Right Way' is to follow GLSAs and to remember every ebuild you installed on every machine and patch them accordingly. It works when you have just a few servers or a bunch of identical servers, but it can be painful when you happen to have several different servers.

I have RedHat servers and while I read RedHat advisories, I still use RedHat erratas together with apt-rpm repositories so that an apt-get update/upgrade brings my system up to date with all erratas (without having to do each update manually or subscribing to up2date )

So it will be made much simpler with an emerge world --security. Once the flag is implemented in portage (I must admit I have no idea how complex it is ), the task of setting the flag on a specific package will be the responsability of the GLSA publisher...

Are you assuming that a Gentoo box is not secure as it is?
Of course, nothing is 100% secure, and never will be, but assuming that there should be an emerge security, only emplies that 'more' security can be added to the system. I completely disagree with this idea._________________Lego my ego, and I'll lego your knowledge

Are you assuming that a Gentoo box is not secure as it is?
Of course, nothing is 100% secure, and never will be, but assuming that there should be an emerge security, only emplies that 'more' security can be added to the system. I completely disagree with this idea.

A Gentoo box is no more secure when a vulnerability has been found in one of its packages. That's why there are GLSAs and why you should upgrade as soon as a vulnerability is discovered. The whole emerge --security thing is about making the process easier for lazy and/or busy admins.

Are you assuming that a Gentoo box is not secure as it is?
Of course, nothing is 100% secure, and never will be, but assuming that there should be an emerge security, only emplies that 'more' security can be added to the system. I completely disagree with this idea.

A Gentoo box is no more secure when a vulnerability has been found in one of its packages. That's why there are GLSAs and why you should upgrade as soon as a vulnerability is discovered. The whole emerge --security thing is about making the process easier for lazy and/or busy admins.

Oh really.... so emerge -u -p world wouldn't upgrade to those newer packages when they are available? ohhhh Sorry then! *g* (notice the sarcastic tone)

Sorry if I previously missed your point. Yes emerge -u world would upgrade all packages (including the security fixes). Which for my personal workstation is really nice.
The problem is it will also upgrade all my packages on my stable server, on which I prefer not to upgrade anything unless I have to for security reasons. If my server works stable, I don't want to upgrade packages for functionalities I don't need or bugs I didn't encounter.
I think emerge world --security is useful to push Gentoo in the server area. Current emerge functionalities already made it a killer distro for wrokstations

Koon, I think you have hit the nail on the head for system administration. If it's not broken, don't fix it. A primary goal for a server is to provide maximum availability for the expected services. Upgrading a package simply because one exists isn't satisfactory justification. Not to mention the possibility of configuration file changes or other unexpected differences when installing a newer versioned package.

I like the idea myself, but I can see the difficulties from a programming standpoint. I wish I could offer a suggestion, but I felt the need to reinforce Koon's message.

Perhaps a better route to take would be to have emerge security be more like emerge rsync in that it would rebuild a view of the newest packages based only on the packages that are new and have a security flag marked on them. Then you could do something like:

Code:

bash$ emerge security
bash$ emerge -u world

and you would have just updated all the programs that you have installed to their latest secure release. This would allow you to overcome rac's issues with getting packages installed that you don't want and it would still allow for a lazy admin to only update packages that needed serious security updates. Another benefit would be that you could update the security flaws quickly and get your mission critical server back up and running asap. _________________if i never try anything, i never learn anything..
if i never take a risk, i stay where i am..