similar to: rlimit sandbox on cygwin

Hi, The systrace and rlimit sandboxes have been committed and will be in snapshots dated 20110623 and later. This diff adds support for pre-auth privsep sandboxing using the OS X sandbox_init(3) service. It's a bit disappointing that the OS X developers chose such as namespace-polluting header and function names "sandbox.h", "sandbox_init()", etc. It already forced me to

Hi, This patch (relative to -HEAD) defines an API to allow sandboxing of the pre-auth privsep child and a couple of sandbox implementations. The idea here is to heavily restrict what the network-face pre-auth process can do. This was the original intent behind dropping to a dedicated uid and chrooting to an empty directory, but even this still allows a compromised slave process to make new

On 05/05/2016 10:11, Uwe Ligges wrote: > Actually this also happens under Linux and I had my R processes killed > more than once (and much worse also other processes so that we had to > reboot a server, essentially). I found that setting RLIMIT_AS [1] works very well on Linux. But this requires that you cap memory to some fixed value. > library(RAppArmor) > rlimit_as(1e9) >

Hi! I wrote a small patch to enable /etc/limits support in openssh. nice thing when you don't have PAM installed.. It is based on Ultor's openssh 1.x patch (http://marc.theaimsgroup.com/?l=secure-shell&m=96427677022741&w=2) Works fine on slackware7.1. define USE_ETC_LIMITS in config.h , and compile as usual. Sagi -------------- next part -------------- diff -N -u

I was wondering if the following attack would be feasible once I'm able to break into rlimit sandbox. Because sandboxed process that handles unauthenticated session is running as the 'sshd' user I was wondering if this could be used to jump between processes using ptrace(2). For example if I find a bug in the code executed before authentication I could use ptrace(2) to attach to

Package: src:xcp-vncterm Version: 0.1-2 Severity: important Tags: sid jessie User: debian-glibc at lists.debian.org Usertags: ftbfs-glibc-2.17 The package fails to build in a test rebuild on at least amd64 with eglibc-2.17, but succeeds to build with eglibc-2.13. The severity of this report may be raised before the jessie release. The test rebuild was done together with GCC-4.8, so some issues

Hi. New (2.1.1p1) login code is nicer on AIX (4.2.1.0.06). Thanks. A couple of issues, though, which I haven't really dug into yet. I'm wondering if anyone else has seen them? If not, I'll investigate & report. 1. If I set "UseLogin" to "yes", everything seems fine except that the authentication agent forwarding doesn't work. The "SSH"

>>>>> Kirill M?ller <kirill.mueller at ivt.baug.ethz.ch> >>>>> on Wed, 11 May 2016 10:42:56 +0200 writes: > My ulimit package exposes this API ([1], should finally submit it to > CRAN); unfortunately this very API seems to be unsupported on OS X > [2,3]. Last time I looked into it, neither of the documented settings > achieved

Hi, we're in the process of setting up large-page support on IBM regattas, but for large-page support the users have to have a set of extra capabilities (CAP_BYPASS_RAC_VMM,CAP_PROPAGATE). This are configured on a per user basis by listing which capability each user have in /etc/security/user. Unfortunately they don't get set when the users log in via OpenSSH (3.1p1). Does anybody know

I'd like to have something like seq() where I can pass in a length of the desired sequence and a right limit so that the sequence goes up to the limit and then starts again from 1. # works now seq(from=2, length.out=3) [1] 2 3 4 # what I want seq(from=2, length.out=3, rlimit=3) [1] 2 3 1 # additional examples of what I want seq(from=2, length.out=4, rlimit=3) [1] 2 3 1 2 seq(from=2,

https://bugzilla.mindrot.org/show_bug.cgi?id=2011 Bug #: 2011 Summary: sandbox selection needs some kind of fallback mechanism Classification: Unclassified Product: Portable OpenSSH Version: 6.0p1 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2

When changing a file size with fallocate() the new size isn't being checked. In particular, the FSIZE ulimit isn't being checked, which makes fstest generic/228 fail. Simply adding a call to inode_newsize_ok() fixes this issue. Signed-off-by: Lu?s Henriques <lhenriques at suse.de> --- fs/ocfs2/file.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git

Standard apology if old... This demonstrates a resource starvation attack on the setuid root passwd(1) program. In the case I tested it was the Red Hat Linux passwd-0.50-7 program without shadowing. #include <stdio.h> #include <sys/time.h> #include <stdlib.h> #include <unistd.h> #include <sys/resource.h> main () { struct rlimit rl, *rlp; rlp=&rl;

I didn't see this one applied to the repository yet. It may not be the best patch possible... basic problem is that _LARGEFILE64_SOURCE needs to be defined on Solaris 2.6 if AC_SYS_LARGEFILE ends up doing a '#define _FILE_OFFSET_BITS 64' If _FILE_OFFSET_BITS == 64, then <sys/resource.h> will define a 'struct rlimit64' but NOT define a 'struct rlimit' leading to

Can I configure openssh with --sandbox=seccomp_filter and have it still run on older kernels with sandboxing via rlimit? I'm asking from a linux distro packaging point of view. Does --sandbox=seccomp_filter keep the rlimit sandbox? It looks to me as if I can only link in one of the sandbox plugins. An openssh build with seccomp_filter enabled will probably have no sandbox at all on linux <

http://bugzilla.mindrot.org/show_bug.cgi?id=301 Summary: In openssh 3.3 and 3.4 pam session seems be called from non-root Product: Portable OpenSSH Version: -current Platform: All OS/Version: Linux Status: NEW Severity: critical Priority: P3 Component: sshd AssignedTo:

Hi, I'm getting the following error occasional and can't find out why; 05/14/2011 09:28:51 rsyncing /dbtmp to /dbtmp.new (1st pass) .... rsync: writefd_unbuffered failed to write 4 bytes [sender]: Broken pipe (32) rsync: write failed on "/dbtmp.new/file.dmp": File too large (27) rsync error: error in file IO (code 11) at receiver.c(258) [receiver=2.6.9] rsync: connection

This is almost just refactoring, but I also set the memory limit to really 1 GB, and not 1×10⁹. --- src/info.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/src/info.c b/src/info.c index d7f45f0..616ef50 100644 --- a/src/info.c +++ b/src/info.c @@ -56,6 +56,7 @@ static yajl_val get_json_output (guestfs_h *g, const char *filename); static char

Has anyone tried LFS (ie >2G files support) and Ext3 together? Are there good reasons why this should/should not work? I see the RH enterprise kernel patch set specifically does not attempt both lfs and ext3, but the lfs patches themselves touch some reasonably localised parts of ext2, so I would hope (without having dived in there to test), that the ext3 changes would mirror that

Is there any documentation I can look at that might talk about how to put memory limits on mongrel? For instants, I might want to limit mongrel to 100 megs of ram. I know that I can monitor mongrel with monit and restart it automatically if it becomes a ram piggy.