Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A subsystem to restrict programs into a “reduced feature operating model”

marc.info

Post reply on HN
Print view View original

61–70 of 101 posts

Re: A subsystem to restrict programs into a “reduced feature operating model”

#61

Post by philsnow »

stsp wrote: post #58
philsnow wrote: post #50

Earlier quoted context omitted.

I'm `cvs get`ting as fast as I can to read the rest of sys_fork.c to sate my curiosity, but CVS incredibly slow. I'm spoiled by how git packs the repo.

Sounds like you're doing something unnecessarily more complicated than this: $ time cvs -d anoncvs@anoncvs1.ca.openbsd.org:/cvs export -rHEAD src/sys/kern/kern_fork.c U src/sys/kern/kern_fork.c 0m2.73s real 0m0.06s user 0m0.04s system

Yep, I was grabbing `src` instead of `src/sys/kern/kern_fork.c`. I've completely forgotten how to CVS, and I'm okay with that.

Re: A subsystem to restrict programs into a “reduced feature operating model”

#62

Post by programmer_dude »

Animats wrote: post #60

Having fine-grained capabilities and the ability to turn them off is always useful. The usual problem is that some component needs to, say, open a file, so all code gets "open file" privileges. There's a tool like this for Android phones. It not only can turn privileges off for an application, but also offers the option to provide apps fake info for things they don't need. You can, for example, deny address book acce…

Whats the name of this app? Can it run without root permissions?

Re: A subsystem to restrict programs into a “reduced feature operating model”

#63

Post by MichaelCrawford »

A simple easy way to keep a lid on privelige escalation is to remove all the files that you computer does not absolutely require to do its job.

Especially the development tools: the Morris worm enabled portability by distributing itself in source code form then building its binary on its target hosts.

My sister once read a novel about some very traditional, strictly religious people who fastened their shirts with string ties as they felt buttons were hooks that the Devil could use to grab hold of you.

I feel much the same way about files. I dont know what tomorrow's zero-day will look like but the chances are quite good that it will depend on a file that is installed by default. Cliff Stoll wrote in "The Cuckoo's Egg" of a subtle bug in a subprogram used by GNU emacs for email. Had the Lawrence Berkeley Laboratory used vi rather than emacs they would not have been vulnerable. ;-D

Yes it is a step in the right direction not to run daemons or windows services you dont need but its even better to remove them.

In 1990 I wrote an A/UX 2.0 remote root exploit to drive home my objection to one single file having incorrect permissions. Its source was about a dozen lines. That particular file was required but our default installs have many files we dont really need.

Also if you can read - not just execute - the binary to any program or library then your malware can load it into its memory then execute it. We have no way of knowing who is going to do that tomorrow but we do know there are many binaroies we do not really need.

If you develop code for your server, install the same distro in a vm on your desktop box then compile it there.

Re: A subsystem to restrict programs into a “reduced feature operating model”

#64

Post by pki »

programmer_dude wrote: post #62
Animats wrote: post #60

Having fine-grained capabilities and the ability to turn them off is always useful. The usual problem is that some component needs to, say, open a file, so all code gets "open file" privileges. There's a tool like this for Android phones. It not only can turn privileges off for an application, but also offers the option to provide apps fake info for things they don't need. You can, for example, deny address book acce…

Whats the name of this app? Can it run without root permissions?

xprivacy/xposed framework, no

Re: A subsystem to restrict programs into a “reduced feature operating model”

#65

Post by stsp »

philsnow wrote: post #61
stsp wrote: post #58

Earlier quoted context omitted.

Sounds like you're doing something unnecessarily more complicated than this: $ time cvs -d anoncvs@anoncvs1.ca.openbsd.org:/cvs export -rHEAD src/sys/kern/kern_fork.c U src/sys/kern/kern_fork.c 0m2.73s real 0m0.06s user 0m0.04s system

Yep, I was grabbing `src` instead of `src/sys/kern/kern_fork.c`. I've completely forgotten how to CVS, and I'm okay with that.

Perhaps you'll like this, then: https://github.com/ustuehler/git-cvs

Re: A subsystem to restrict programs into a “reduced feature operating model”

#66

Post by bch »

ghshephard wrote: post #59
TheLoneWolfling wrote: post #7

So, do I have it right that this is effectively a way of a program being able to declare to the operating system "I shouldn't ever do "? Because, if so, that makes a whole lot of sense. (Adding security "for free" generally does). This could conflict with on-the-fly upgrades, though. If it turns out that some later version of your program does in fact require , then you'll have to kill and restart the process as oppo…

If you read through the examples, it's even better. The default case when you call tame() is that you don't get any privileges, so you explicitly have to call and declare to the operating system, "I need to be able to do - don't let me do anything else."

This sounds like Tcl's "safe interpreter" [1], but for syscalls.

[1] http://www.tcl.tk/man/tcl8.4/TclCmd/safe.htm

Re: A subsystem to restrict programs into a “reduced feature operating model”

#67

Post by vidarh »

nitrogen wrote: post #38

I recently asked for exactly this on StackOverflow, but for Linux[0]. Is anyone aware of an interface to seccomp-bpf on Linux that is as easy to use as this tame() syscall? If not, does anyone want to join forces to create one? An ultra-simple library that provides tame()-like functionality on all capable platforms should make writing secure software a lot easier. [0] https://stackoverflow.com/questions/31373203/drop…

I would look into the Chrome/Chromium sandbox code, as they seem to have at least some facility for parsing simple profiles.

This page has some details:

http://www.chromium.org/chromium-os/developer-guide/chromium...

Re: A subsystem to restrict programs into a “reduced feature operating model”

#68

Post by MichaelCrawford »

MichaelCrawford wrote: post #63

A simple easy way to keep a lid on privelige escalation is to remove all the files that you computer does not absolutely require to do its job. Especially the development tools: the Morris worm enabled portability by distributing itself in source code form then building its binary on its target hosts. My sister once read a novel about some very traditional, strictly religious people who fastened their shirts with str…

It is common for executables to have these permissions:

rwxr-xr-x

maybe this is better:

--x--x--x

what that means is that you can run the program but you cannot read it as a regular file.

To delete or create a file you must have write permission to the directory it is or will be found in.

Yes it's a PITA to take away your own permissions but your server is not the box you take with you when you hang out at Starbucks.

Re: A subsystem to restrict programs into a “reduced feature operating model”

#69

Post by evincarofautumn »

ghshephard wrote: post #52

This is pretty brilliant/obvious in hindsight. In addition to the sandboxing protection, you also have a really good inventory of what privileges the application requires. Looking over the diffs in the applications - most of them are two or three lines - a #include followed by something simple like tame(TAME_STDIO | TAME_DNS | TAME_INET); What I really like about a lot of the OpenBSD initiatives, is they don't overth…

Yeah, it’s a basic dynamic role/coeffect system, which goes a long way toward enforcing correctness and safety, much as types do (whether static or dynamic).

Re: A subsystem to restrict programs into a “reduced feature operating model”

#70

Post by raverbashing »

Animats wrote: post #60

Having fine-grained capabilities and the ability to turn them off is always useful. The usual problem is that some component needs to, say, open a file, so all code gets "open file" privileges. There's a tool like this for Android phones. It not only can turn privileges off for an application, but also offers the option to provide apps fake info for things they don't need. You can, for example, deny address book acce…

Yeah, for 'open file' kind of stuff it would be better to have a real sandbox (I think Windows began doing something like this, not sure if in Vista or 7, that if programs wanted to write to certain restricted places they can - but this is written to their sandbox, so if they read it later they can get the files but with no effect on the system files)
Post reply on HN