Aura - 4.0.4 - The Multilingual Package Manager

evujumenuk · 2013-07-23 12:55:14

I never said that I run aura with sudo. I (would like to) run Aura as root.

(If you are interested, the rationale is (pretty much) this: http://www.openwall.com/lists/owl-users/2004/10/20/6)

jryan · 2013-07-23 13:30:13

zoqaeski wrote:

Could you add a shorthand option to enable editing of PKGBUILDs? I prefer to edit them before building, but typing ‘--hotedit’ all the time gets a little annoying. ‘-e’ doesn’t seem to conflict with anything. Also, sometimes Aura will ask twice if you want to edit the PKGBUILD.

I agree. You could probably create an alias in the meantime, however:

alias aura.e='aura --hotedit'

fosskers · 2013-07-24 00:56:18

@evujumenuk: Ah. Are you doing sysadmin stuff, like over ssh?

And I'm aware that I need to rework a few things to:
1. Fix package build failures.
2. Make the choice to edit not appear twice.
3. Get batch building back.

evujumenuk · 2013-07-24 12:49:49

No, I don't ssh into my Arch box. I use a separate virtual console to log in as root and do administration there. I also use another virtual console to log in as my makepkg user. So, it would be great if I could use aura as root, upon which aura would fork a makepkg with my makepkg user (the name of which would be defined on the command line or in a config file) via something akin to su -c, build the package with that, then install the generated package as root. Something like that. As long as both accounts do not share tty devices, the attack surface would be limited to injection of malicious code in the built package.

In other words, it'd be great if sudo (changing the user "upwards", as opposed to su -c from root, "downwards") wasn't required, while building and installing were still separated.

Last edited by evujumenuk (2013-07-24 12:50:12)

fosskers · 2013-07-25 00:48:29

I suppose if I finally caved and made a config file, you could set a `build user` field which would determine what user to `su -c` to. This is in fact what already happens, except that Aura checks environment variables to see what user used sudo in the first place, then calls `su -c` with it.

evujumenuk · 2013-07-25 09:06:17

Well, I wouldn't mind using environment variables to define a user to run makepkg as, like

MAKEPKG_USER=makepkg aura -Akua

or something.

Edit: Would you advise against abusing SUDO_USER for this? For now, I mean.

Last edited by evujumenuk (2013-07-26 13:29:20)

fosskers · 2013-07-26 23:17:46

I went and made a flag for it. It'll be included in the next release in two days or so.
If you run aura with `--builduser=username` it should do what you're looking for.

evujumenuk · 2013-07-26 23:56:40

Looking forward to it; thanks!

kaszak696 · 2013-08-04 16:33:30

I found a strange behavior of Aura, when i'm trying to install jdownloader2 through -A, i get this sort of error:

kaszak@localhost ~ (git)-[master] % LANG=C aura -A jdownloader2
aura >>= Determining dependencies...
aura >>= Dependency checking failed for these reasons:
The dependency `java-runtime` demands version `>=1.5` but its providing package `jre7-opndk` gives version ``

Looks like Aura on my machine caught dyslexia or something, the package in question should be jre7-openjdk. Any idea why it's crunching letters?

Psirus · 2013-08-06 01:50:28

Aura has become really slow all of the sudden. What could this be?

time aura -As archey
aur/alsi 0.4.5-1 (189)
    ALSI: a configurable system information tool for Arch Linux. [Inspired by Archey]
aur/archey 20130324-3 (566)
    Simple python script that displays the arch logo and some basic information.Depends on python3
aur/archey2 20121013-1 (9)
    Simple python script that displays the arch logo and some basic information. Python 2.x version
aur/archey3 0.4.29.gb4cc4bb-1 (271)
    Python script to display system infomation alongside the Arch Linux logo.

real	2m7.813s
user	0m0.030s
sys	0m0.000s

fosskers · 2013-08-06 08:26:32

@kaszak: 1.2.1.0 should fix that.
@Psirus: Not sure.

---

New release! - 1.2.1.0
- New `builduser` option
- `Prelude.head` bug fixed
- Dependency checking is faster
- New `-k` output
- `--absdeps` works properly now
- Other bug fixes

orschiro · 2013-08-06 08:29:56

Great!

Can you please update aura-bin?

gondsman · 2013-08-13 19:59:52

I don't know if this was addressed before, but it seems like there's something wrong with the way aura addresses build dependencies for AUR packets. I was trying to update google-talkplugin, which depends on gtk2. Now, I have gtk2-ubuntu installed, which of course provides gtk2, but aura insisted on wanting to install the standard gtk2 from the repos (and thus removing gtk2-ubuntu). I had no trouble updating with yaourt on the other hand.

fosskers · 2013-08-14 05:49:08

This has been fixed. Please upgrade to 1.2.1.1

evujumenuk · 2013-08-15 21:33:08

Two questions:

When aura calls external processes such as pacman or makepkg, does it hand over the terminal? Processes can use the TIOCSTI ioctl to inject fake keypresses, which becomes a security problem when a less-privileged process can simulate actions of a more-privileged user.
AFAICT, aura parses PKGBUILD files itself. That means it understands how to handle {md5,sha1,sha256,sha384,sha512}sums. It would be great if there was an aura option that aborts the build if any sources have missing or skipped hashes.

fosskers · 2013-08-16 00:58:49

1. That sound serious but I'm not sure what you mean by "hand over the terminal".
2. I believe `makepkg` would abort the build itself if the hashes didn't match.

evujumenuk · 2013-08-17 12:59:41

By that I mean "share their controlling terminal". This is not just about std{in,out,err}; processes can (and in the case of processes set off in some way by a logged in user, do) have a controlling terminal associated with them that, if shared, allows the aforementioned circumvention of security boundaries.

The usual defense against processes acquiring a controlling terminal is double-forking. However, this implies that the parent process cannot read the return value of its child upon its exit.

Regarding the hashes, yeah, makepkg would abort on mismatched hashes, but AFAIK doesn't do anything about hashes that are either missing entirely (empty or nonexistent *sums arrays) or containing SKIP directives. I'd like aura to (optionally) abort the build if there is no valid hash for at least one the source files. This would mean that I wouldn't have to trust my sources individually, I would only need to trust the PKGBUILD file('s author).

evujumenuk · 2013-08-17 13:16:15

A few extra remarks. AFAIK, for the TIOCSTI ioctl to succeed, one either has to have CAP_SYS_ADMIN (and if one has that, they're practically root already anyway) or the fd one performs this ioctl on has to be the controlling terminal of the calling process. So I guess using the same pts device as stdin, stderr, stdout is fine. Still, I guess pacman would need to be called with --noconfirm, though.

I guess that if one trusts pacman and makepkg to do the right thing (which would be not opening tty devices after starting - at least makepkg can conceivably violate that), a single fork would be sufficient. I *think* however that the first (and in this case, only) fork would need to call setsid() to make itself a session leader. Since I don't think that pacman or makepkg do that, a double fork is still required.

With a double fork, the two processes would be truly dissociated. aura would have to wait for the new PID's exit and find out whether it was successful via some means other than the return value.

Yeah, UNIX programming is fun.

Last edited by evujumenuk (2013-08-17 13:34:37)

evujumenuk · 2013-08-18 14:57:47

Oh, would you look at that.

shadow-4.1.4.3 -> shadow-4.1.5					2012-02-12

*** security
  * su -c could be abused by the executed command to invoke commands with
    the caller privileges. See below. (CVE-2005-4890)

Which means that su in the shadow package does defend against that problem, which even has a CVE number. Arch, however, prefers to use the util-linux of many shadow-provided utilities, including chsh, chfn, su, logoutd, login, vipw and vigr. (Cf. https://projects.archlinux.org/svntogit … ges/shadow) I am unaware of any specific reason other than "they had to pick one", I see no point on which the su in util-linux (and before that, coreutils) would be technically superior.

So, I guess this whole class of su-related problems can be avoided for all programs (not just aura) if someone convinces the devs to switch to shadow for su. TBH, that's a way better place to handle this than aura.

falconindy · 2013-08-18 15:46:45

So, because shadow fixes a known CVE 7 years after it's reported (and a year after the debian bug report), you claim that shadow is a reasonable project to follow? The 4.1.5 release had multiple crashes/breakages and removed features that the maintainer "didn't know" were still in use. Despite all of these problems being reported (with patches!) within the first week after the release, it still took the maintainer 3 1/2 months to get a point release out the door. To this day, there are still numerous buffer overflow vulnerabilities in shadow due to amateur hour programming with functions like strcpy (called 34 times), strcat (called 12 times), and sprintf (called 35 times).

No thanks, I'm taking every chance I get to abandon ship with shadow and move to coreutils or util-linux. I can only assume that you haven't actually looked at util-linux's implementations to see if the injection vulnerability existed. Otherwise, you would have found this commit.

Sorry for the hijack, but I loathe shadow for reasons too numerous to keep track of.

evujumenuk · 2013-08-18 20:04:22

Thanks for your input!

As you're certainly aware, this problem has existed for almost 30 years (http://securitydigest.org/unix/archive/015) and has, pretty much, become part of "the UNIX experience". So it's not like the CVE had any major significance in the first place -- certainly, it never started a race to fix this security issue. (Still, a secure package manager should address this in some way.) And I didn't claim anything, I just stated I was not aware of any technical differences. So, thanks for your input there.

You're right, I didn't look at the code. That's because I was under the impression that util-linux adopted their implementation of su from coreutils when they abandoned it, and the coreutils maintainers never did anything to address this vulnerability.

So, if aura never neglects to use su -c to start less-privileged programms, we should be safe, right?

falconindy · 2013-08-18 20:14:20

There's lots of reasons not to use su, the least of them being security issues. The best way to drop permissions is to never acquire them in the first place. Rather, request escalation only when required and limit the scope of the escalation.

I completely fail to understand how a package manager should be involved in any way here.

evujumenuk · 2013-08-18 21:12:55

If you do this once and your account has been backdoored, escalating to root is possible afterwards without any hindrance; the account effectively becomes root. Example: sudo is supplanted by a program that accepts a password, logs it, then passes it to "real sudo". Bad Guys™ win.

In the su -c scenario, makepkg only has the chance of tainting the built package to cause any damage. (Well, and TIOCSTI, but that is no more, supposedly.) It's better to never give unprivileged processes a chance to escalate to root.

A package manager is involved if makepkg becomes involved. Without it, just do anything as root (like pacman does).

orschiro · 2013-10-12 07:38:53

Is there a way to check VCS packages for updates?

The command `aura -Akua` at least does not automatically check for VCS packages updates.

Procedural · 2013-10-12 10:12:37

Hey man, first of all - this is a must have app for an arch user, thank you for making it!

I have a little proposal, would be cool if you could add it - I builded tomahawk today - jreen was nessesary to build it, but it gave an error during compilation. There is two aur packages, jreen and jreen-git available (sometimes there is *-bzr alternatives also) and jreen-git builds totally fine. Could Aura offer in this case to build alternatives instead?

Arch Linux

#151 2013-07-23 12:55:14

Re: Aura - 4.0.4 - The Multilingual Package Manager

#152 2013-07-23 13:30:13

Re: Aura - 4.0.4 - The Multilingual Package Manager

#153 2013-07-24 00:56:18

Re: Aura - 4.0.4 - The Multilingual Package Manager

#154 2013-07-24 12:49:49

Re: Aura - 4.0.4 - The Multilingual Package Manager

#155 2013-07-25 00:48:29

Re: Aura - 4.0.4 - The Multilingual Package Manager

#156 2013-07-25 09:06:17

Re: Aura - 4.0.4 - The Multilingual Package Manager

#157 2013-07-26 23:17:46

Re: Aura - 4.0.4 - The Multilingual Package Manager

#158 2013-07-26 23:56:40

Re: Aura - 4.0.4 - The Multilingual Package Manager

#159 2013-08-04 16:33:30

Re: Aura - 4.0.4 - The Multilingual Package Manager

#160 2013-08-06 01:50:28

Re: Aura - 4.0.4 - The Multilingual Package Manager

#161 2013-08-06 08:26:32

Re: Aura - 4.0.4 - The Multilingual Package Manager

#162 2013-08-06 08:29:56

Re: Aura - 4.0.4 - The Multilingual Package Manager

#163 2013-08-13 19:59:52

Re: Aura - 4.0.4 - The Multilingual Package Manager

#164 2013-08-14 05:49:08

Re: Aura - 4.0.4 - The Multilingual Package Manager

#165 2013-08-15 21:33:08

Re: Aura - 4.0.4 - The Multilingual Package Manager

#166 2013-08-16 00:58:49

Re: Aura - 4.0.4 - The Multilingual Package Manager

#167 2013-08-17 12:59:41

Re: Aura - 4.0.4 - The Multilingual Package Manager

#168 2013-08-17 13:16:15

Re: Aura - 4.0.4 - The Multilingual Package Manager

#169 2013-08-18 14:57:47

Re: Aura - 4.0.4 - The Multilingual Package Manager

#170 2013-08-18 15:46:45

Re: Aura - 4.0.4 - The Multilingual Package Manager

#171 2013-08-18 20:04:22

Re: Aura - 4.0.4 - The Multilingual Package Manager

#172 2013-08-18 20:14:20

Re: Aura - 4.0.4 - The Multilingual Package Manager

#173 2013-08-18 21:12:55

Re: Aura - 4.0.4 - The Multilingual Package Manager

#174 2013-10-12 07:38:53

Re: Aura - 4.0.4 - The Multilingual Package Manager

#175 2013-10-12 10:12:37

Re: Aura - 4.0.4 - The Multilingual Package Manager

Board footer