ArchLinux security advisories

lumiwa · 2006-04-17 16:00:58

Gullible Jones wrote:

iphitus wrote:
They dont protect against buffer overflows. They might claim to, but they wont always pick them up. In saying that, you're falling into reason 1, as there's still a helluva lot of ways to access a system and none of these tools will do what you seem to believe they will..
James
Yes, there are always a lot of ways in, but it's prudent to reduce the number of them. I'm not saying that a hardened kernel is an excuse to use a weak password, or anything braindead like that, I'm just pointing out that simple things like buffer overflows can be exploited by malicious software to gain system access without the user doing anything stupid. I know Linux hasn't gotten like Windows yet, where you can get infected without even doing anything, but having been there I don't want to go that way again. I'm just saying that some things need to be done to remove some of the potential for exploits that are beyond users' control; the rest a healthy dose of paranoia can handle.
Regarding hardened kernels, though... you're saying that they're not actually very effective in the purpose they were designed for? I could definintely believe that, but could you give me an example?

I like to have more secure kernel too. I have a Linux because I want to be more safe than if I have Windows. Am I?
Before when I had a Debian or SuSE I felt secure. Now almost five month on Arch I am not sure...and I don't like to change a distro...

LB06 · 2006-04-17 16:42:47

I do believe that those patchsets are the future. At we least we definitely have to move beyond the disaster called DAC. Soon we will end up with an obsolete argument about having better security.

I suppose that by the end of this year it will be Microsoft who's laughing, because by that time they will already have implemented and thoroughly tested a granular and high flexible security model, based on MAC or RBAC. And Mr. Gates can rightfully claim victory over Linux and BSD.

I can already see it happen. "Ha! Linux and BSD are far more secure!". - "Dude, shut up, you guys have a model that requires the ability to be able to wreck the entire system just to add a user to the system or to globally install a simple app. ROFLOL!!!"

That is the weakest point of *NIX, imho. There's absolutely NO separation of duty, and the principle of least privilege is something they've never even heared of.

Neuro · 2006-04-17 17:34:54

I'm sorry, but this is utter BS.

First of all your fears of Microsoft being able to ship a really secure system are overexaggerated. While everything will look superb on paper and plans, I don't think they'll be able to "thoroughly" test it as you said. Just look a the cut-down of features and the rush that's associated with Vista.

And with regard to Linux and BSD, you're only spreading FUD. You don't have to give anyone all of the root permissions to add a user, nor to install and application. You can use sudo, so that co-administrators can manage their part of the system. This, plus filesystem permissions (or FS ACLs), are a similar way of delegating privileges to what you can find in the fancy policies you mentioned earlier.

There's absolutely NO separation of duty, and the principle of least privilege is something they've never even heared of.

Have you ever read a book on *NIX security? It all boils down to the principle of least privilege/trust.

LB06 · 2006-04-17 18:23:10

ls -hl /etc/shadow
-rw------- 1 root root 322 2006-04-03 11:11 /etc/shadow

This directly violates the principle of least privilege.

Gullible Jones · 2006-04-17 18:58:49

Umm pardon? The least privilege you should have to look at file containing everyone's freakin' password hashes should be superuser. There is a good reason for that.

IMHO a better example of violation of the principle of least privilege is X running as root. I think it would be better if it ran as its own user, with various limitations to make it more difficult to use as a tool for rooting a system.

Gullible Jones · 2006-04-17 19:00:51

BTW, how does AppArmor fair, as far as being a PITA goes?

LB06 · 2006-04-17 20:55:51

Gullible Jones wrote:

Umm pardon? The least privilege you should have to look at file containing everyone's freakin' password hashes should be superuser. There is a good reason for that.
IMHO a better example of violation of the principle of least privilege is X running as root. I think it would be better if it ran as its own user, with various limitations to make it more difficult to use as a tool for rooting a system.

The problem with the file being owned by root:root@0600 is that, in order to do something with that file, you need to become root. By becoming root, you inherently gain ALL other superpowers on that system. Why would you want rights to rm -fr / everything if all you need to do is simply add a freaking user?

wikipedia wrote:

In computer science and other fields the principle of minimal privilege, also known as principle of least privilege or just least privilege, requires that in a particular abstraction layer of a computing environment every module (which can be for example, a process, a user or a program on the basis of the layer we are considering) must be able to see only such information and resources that are immediately necessary.

Gullible Jones · 2006-04-17 21:25:01

Hmm, good point.

Neuro · 2006-04-17 21:53:02

LB06 wrote:

The problem with the file being owned by root:root@0600 is that, in order to do something with that file, you need to become root. By becoming root, you inherently gain ALL other superpowers on that system. Why would you want rights to rm -fr / everything if all you need to do is simply add a freaking user?

Alright, that's a good point. Unless of course you'd see the other side of it.

Let's presume you're in a RBAC system. To add a user you, or the program you are running (for which you need privileges to run), need to have privileges to alter user accounts. To do that, you need to be able to grant him privileges to be a user, thus you or the program you are running needs to have privileges to alter privileges. So, theoretically, you could somehow force that program (by for example exploiting it) to grant you as the user, all privileges on the system. How is that different?

It's not the case of the policy, it's the case of how exploitable your tools are. Rarely anyone adds users by hand today anyways. And, AFAIK adduser is pretty safe.

Neuro · 2006-04-17 22:00:58

I got a bit tired with this super-user vs policy system debate.
Privileges aren't that important really. Maybe RBAC or whatever systems are the future, but if you ask me, they're for the paranoid. You'd still be able to compromise such a system if the software it's running was buggy and vulnerable.
And that's the major threat to security. The best way to be secure is to keep your system up to date.

LB06 · 2006-04-17 22:13:20

Neuro wrote:

LB06 wrote:
The problem with the file being owned by root:root@0600 is that, in order to do something with that file, you need to become root. By becoming root, you inherently gain ALL other superpowers on that system. Why would you want rights to rm -fr / everything if all you need to do is simply add a freaking user?
Alright, that's a good point. Unless of course you'd see the other side of it.
Let's presume you're in a RBAC system. To add a user you, or the program you are running (for which you need privileges to run), need to have privileges to alter user accounts. To do that, you need to be able to grant him privileges to be a user, thus you or the program you are running needs to have privileges to alter privileges. So, theoretically, you could somehow force that program (by for example exploiting it) to grant you as the user, all privileges on the system. How is that different?
It's not the case of the policy, it's the case of how exploitable your tools are. Rarely anyone adds users by hand today anyways. And, AFAIK adduser is pretty safe.

Correct, but the risk is significantly lowered. Now if someone wants to crack the entire system, one needs to find a weak spot in the privilige assignment system.

But in the current situation, a cracker could use the privilege system OR any daemon that runs as superuser OR has the UID bit set and is owned by root. That leads to an increased exposure, doesn't it? Fortunately more and more services are moving to ordinary users, which is definitely good.

Yeah, adduser is pretty much safe (although there were exploits, if I remeber correctly), but what about X, acpid, kdm, ntpd, dhcpcd, hal, to name a few? These services run as root by default. SSH and mysql also seem to have some process run as root.

mindtriggerz · 2006-04-19 01:21:52

AFAIK, sudo, *IF CONFIGURED PROPERLY*, can give all the benifits of a policy-based system.
I tend to like the Windows file control system alot better for multiple user systems, though.

Gullible Jones · 2006-04-19 01:59:53

There's instructions for stuff like that in the Wiki - disabling the root account and using an account with full sudo privileges instead... Also Ubuntu has a setup like that by default IIRC, although they recently had a rather nasty vulnerability appear - the password for the admin user was visible as plain (unencrypted) text in the log files.

Now for something completely different though... Why wasn't W^X implemented as a default on Linux a long time ago? PaX and ExecShield both seem to provide it, but they are not compatible with certain applications - IIRC, OpenBSD (which uses W^X) doesn't have such compatibility problems, unless the OpenBSD devs are major bogon sources.

WillySilly · 2006-04-19 02:01:06

If anyone is interested in actually going ahead with the Security Task Force you'll probably want to refine the page more and start bugging the devs

LB06 · 2006-04-19 19:57:14

Having a sudo account with all powers doesn't actually help much in light of the least privilege principle. The only thing that can be achieved here is that one does not have to share a password, which could be a problem if the admins come and go.

edit: @mindtriggerz
Sudo could probably be used to assign least privileges to users or groups (e.g. allow only `{add,mod,del}user` for a user who has to maintain the set of users. But there are several problems here:

- Most importantly, there's no least privilege on application level. For example, if there's an exploit in adduser, it could still be used to execute malicious code as a superuser. In order to solve this, one would have to define a set of rules for each application/user combo, which is essentially writing a MAC system.
- What if someone is allowed to see file1, but not file2? Afaik, it is not possible to define that you can only cat, grep, less or more file1. And if it is, it'll become unmaintainable very quickly. Managing permissions on a command based principle just doesn't work.

mindtriggerz · 2006-04-19 22:13:44

@LB06: You're right. However, there's not (m)any OSes that I've seen that fully implement least privledge. And the *nix filesystem security paradigm is fundementally incompatible with "Windows-style" granular control.

Neuro · 2006-04-20 07:07:24

The biggest problem with Vista's policy controll would be.. it's complexity.
It'll require extensive knowledge to understand and, due to it's "granularity", some time to configure.

Now, most of the people will either be lazy or lack the time to set it up properly, so most of the time the default configuration will be used. And, Microsoft won't make these defaults strict and safe enough, since they provide the users with backwards-compatibility.

As for the superuser approach. Well, most of the people know that the root account is an evil thing, not to mess around with. And, the most important thing of all, most people know that they should watch for root-running daemons and SUID programs. While it won't be able to provide as much security as the privilege-based system, I agree with you on this, it's far simpler to both understand and manage.

It's the human nature, laziness in this case, that's always the weakest link.

mindtriggerz · 2006-04-20 20:26:03

I just read in my latest issue of eWeek that Vista will have over 3,000 Group Policy settings. So, yeah, the default will be used most of the time.

jfryman · 2006-04-21 14:49:51

WillySilly wrote:

If anyone is interested in actually going ahead with the Security Task Force you'll probably want to refine the page more and start bugging the devs

Trying to get the thread back on topic.....

I've been working on looking at the Security Task Force List and how it could potientally apply to ArchSecurity Advisories as a whole. I'll be setting up a basic blog on blogger.com to determine if it will be useful, and so that there won't be too much hassle on the part of the devs to add this to their place initally... if it becomes necessary in the future we can get it sanctioned by the powers that be... but for now I'm just trying to contribute back to the community.

My wife is out of town this weekend so I'm hoping that I'll be able to hash out the beginnings. I'll keep everyone updated.

-James

jfryman · 2006-04-21 15:25:25

How would dev's or TU's look at interm packages?

Obviously, some packages will have a higher priority to update if a critical security vuln is found... but if an STF member zips an email to a dev, and after some amount of time no response or package... what if an interm PKGBUILD was released to 'plug the hole'...

Would this be acceptable or allowed?

Thoughts?

copernikus · 2006-04-21 15:44:44

jfryman wrote:

How would dev's or TU's look at interm packages?

Not sure how others feel about this, but if it is possible, set up a new location in aur for Security. Unfortunately, I suspect there will be duplicate pkgbuilds.

-Fran

jfryman · 2006-04-21 15:53:36

copernikus wrote:

jfryman wrote:
How would dev's or TU's look at interm packages?
Not sure how others feel about this, but if it is possible, set up a new location in aur for Security. Unfortunately, I suspect there will be duplicate pkgbuilds.
-Fran

And frankly, that is something I want to avoid... the biggest issue here is going to be that of communication between the STF and the Devs... primarily because the entire project [Arch] is volunteer driven.

The other side of that coin would be instead of being proactive in security fixes... having STF members keep track of updated packages and release notification as soon as an update is made. The problem with this again comes down to release time, where packages with high priority will be updated almost immediately and low priority packages may sit for a while.

I'm trying to find the healthy medium.......

-James

jfryman · 2006-04-24 20:17:13

An update:

I'm glad there is interest in this project! Canyonknight and I have been working on updating the STF proposal and coming up with some ideas on how to best manage this service to the Arch community. Once the Wiki is updated, we'll let you know for community review before we head out charging!

I'm looking for some clarification from the developers on this one. One of the main ideas that we're looking at doing is creating some sort of ticket-based system to help the various members of the Security Team track the various responses sent to the developers once a vulerability is made without overlap.

Once of the ideas was to create a separate tracking system (similiar to flyspray) for the Security Team. From there, we could monitor what devs have been contacted regarding specific notes. However, I realize that a bug-tracking system exists already for Arch (bugs.archlinux.org).

Another thought would be to allow the security team to use this as a way to contact the devs in the event of a security vulnerability. This could be a separate user-group within Flyspray - with a new category (Vulnerability Update). It was brought up that this might become abused as users would create a ticket and mark it as 'security vulnerability' only to get a specific package updated. A way around this would be tight ACL's, restricted only to the security team, or an equally fun solution.

I'm curious to hear some of the dev's opinions on this idea. I'm open to sugguestion. Thanks!

user · 2006-04-24 23:45:21

There is plenty of debian, fedora, ubuntu security patches set.
If i were STF, i will consider how to apply these patch set to arch repository..

diff, patch, or upgrade tarball itself.

jfryman · 2006-04-26 15:28:00

I've updated the Wiki for the Security Task Force. Please take a look at it here:

http://wiki.archlinux.org/index.php/Security_Task_Force

I would really like to get the opinion of some of the devs... to make sure I'm on the right page here before I start bugging the devs. Also, I'd like to know if it would be better to start a new mailing-list or rss feed for this project, or to use the existing arch-users mailing list.

Thoughts and comments would be greatly appreciated!

-James

Arch Linux

#26 2006-04-17 16:00:58

Re: ArchLinux security advisories

#27 2006-04-17 16:42:47

Re: ArchLinux security advisories

#28 2006-04-17 17:34:54

Re: ArchLinux security advisories

#29 2006-04-17 18:23:10

Re: ArchLinux security advisories

#30 2006-04-17 18:58:49

Re: ArchLinux security advisories

#31 2006-04-17 19:00:51

Re: ArchLinux security advisories

#32 2006-04-17 20:55:51

Re: ArchLinux security advisories

#33 2006-04-17 21:25:01

Re: ArchLinux security advisories

#34 2006-04-17 21:53:02

Re: ArchLinux security advisories

#35 2006-04-17 22:00:58

Re: ArchLinux security advisories

#36 2006-04-17 22:13:20

Re: ArchLinux security advisories

#37 2006-04-19 01:21:52

Re: ArchLinux security advisories

#38 2006-04-19 01:59:53

Re: ArchLinux security advisories

#39 2006-04-19 02:01:06

Re: ArchLinux security advisories

#40 2006-04-19 19:57:14

Re: ArchLinux security advisories

#41 2006-04-19 22:13:44

Re: ArchLinux security advisories

#42 2006-04-20 07:07:24

Re: ArchLinux security advisories

#43 2006-04-20 20:26:03

Re: ArchLinux security advisories

#44 2006-04-21 14:49:51

Re: ArchLinux security advisories

#45 2006-04-21 15:25:25

Re: ArchLinux security advisories

#46 2006-04-21 15:44:44

Re: ArchLinux security advisories

#47 2006-04-21 15:53:36

Re: ArchLinux security advisories

#48 2006-04-24 20:17:13

Re: ArchLinux security advisories

#49 2006-04-24 23:45:21

Re: ArchLinux security advisories

#50 2006-04-26 15:28:00

Re: ArchLinux security advisories

Board footer