RE: mlock and jail
But a simple user with no rights can mlock (64kb by default) why a jail would not be able? From: Xin LI<mailto:delp...@gmail.com> Sent: Thursday, February 2, 2017 1:13 PM To: Pavel Timofeev<mailto:tim...@gmail.com> Cc: Bruno Lauzé<mailto:brunola...@msn.com>; freebsd-current<mailto:freebsd-current@freebsd.org> Subject: Re: mlock and jail On Thu, Feb 2, 2017 at 7:54 AM, Pavel Timofeev <tim...@gmail.com> wrote: > 2017-02-02 4:31 GMT+03:00 Xin LI <delp...@gmail.com>: >> I like this idea. >> >> Note that potentially your patch would make it possible for a jailed >> root to DoS the whole system by locking too much of pages in memory. >> I think it would be sensible to provide a per-jail flag to enable >> doing it, or better, have some finer grained control (e.g. per jail >> quota of permitted locked pages). >> >> Why did the application want to lock pages in main memory, though? > > For example, this secret management tool > https://www.vaultproject.io/docs/config/ wants to lock memory for > security (surprise) reason. > It's available as security/vault in our ports tree. No it's not surprise but overkill IMHO. Here is why: Locking memory does prevent swapping, but in a typical multi-user system, if an attacker is already able to read swap (keep in mind that disks are by default owned by root and can not be read in a typical setup), then the administrator already have much bigger problem to worry about, and the attacker would have much more powerful tools to steal the secrets. Additionally, if one really cares about safety of swap, they should have used encrypted swap in the first place. On FreeBSD, appending '.eli' to the swap device in fstab (e.g. /dev/ada0p3 -> /dev/ada0p3.eli) would automatically do one-time keyed swapping. Moreover, I don't think it's a good idea to use an application that advocates locking all memory that it owns for "security" reasons: if the application writer does not know which memory pages would contain sensitive information, good chances that the application writer have no idea what is privilege separation and the design they have created could be fundamentally flawed. Cheers, ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: mlock and jail
Thanks you. The app in fact is dotnet https://github.com/dotnet/coreclr And since it's already possible to cap overall memory with rctl ( -- jail:httpd:memoryuse:deny=2G/jail -- or -- jail:httpd:memorylocked:deny=1G/jail -- ) it seems correct to say the lock weight could only be within those limits? But right now memorylocked rctl does apply since prison is denied mlock. I might be missing something. Thanks for your help. By the way, FreeBSD would gain a lot pushing for dotnet support as it did with Java in the days. From: Xin LI <delp...@gmail.com> Sent: February 1, 2017 8:31:35 PM To: Bruno Lauzé Cc: freebsd-current Subject: Re: mlock and jail I like this idea. Note that potentially your patch would make it possible for a jailed root to DoS the whole system by locking too much of pages in memory. I think it would be sensible to provide a per-jail flag to enable doing it, or better, have some finer grained control (e.g. per jail quota of permitted locked pages). Why did the application want to lock pages in main memory, though? On Wed, Feb 1, 2017 at 3:52 PM, Bruno Lauzé <brunola...@msn.com> wrote: > > I would like to ask if there is a reason I would have to applythe patch > below to make an application work in a jail. > And who's bad? the app too intrusive or the bsd not flexible enough > (allow.mlock?) > > > Index: sys/kern/kern_jail.c > === > --- sys/kern/kern_jail.c(revision 313033) > +++ sys/kern/kern_jail.c(working copy) > @@ -3340,6 +3340,11 @@ > case PRIV_PROC_SETLOGINCLASS: > return (0); > > > +case PRIV_VM_MADV_PROTECT: > +case PRIV_VM_MLOCK: > +case PRIV_VM_MUNLOCK: > +return (0); > + > default: > > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
mlock and jail
I would like to ask if there is a reason I would have to applythe patch below to make an application work in a jail. And who's bad? the app too intrusive or the bsd not flexible enough (allow.mlock?) Index: sys/kern/kern_jail.c === --- sys/kern/kern_jail.c (revision 313033) +++ sys/kern/kern_jail.c (working copy) @@ -3340,6 +3340,11 @@ case PRIV_PROC_SETLOGINCLASS: return (0); + case PRIV_VM_MADV_PROTECT: + case PRIV_VM_MLOCK: + case PRIV_VM_MUNLOCK: + return (0); + default: ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
sys/contrib/libnv
Revision 285139 broke options ZFS because of filename collisionCan we rename .c files in sys/contrib/libnv to avoid zfs libnv files dnvlist.c - ldnvlist.c nvlist.c - lnvlist.cnvpair.c - lnvpair.c There is already bug 201356 for this. I confirmed it's working... ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
reboot on wheel
Is there a reason for this: @wheeluser: rebootOperation not permitted@wheeluser: shutdown -r nowSystem halt What's the difference? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
libdevattr
I was looking at dragonfly and why they have libdevattr and we don'tI really think having udev compatible api would open the door to a lot of software, imho.I feel it wouldn't be so complicated to port dragonfly kern_udev, libprop and libdevattr from dragonfly bsd. Am i missing a point or is this in contradiction witch any of freebsd objectives? Let me know your thoughts... ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
vmmapi.h
building from trunk: usr.sbin/bhyve/pci_emul.c is picking up old vmmapi.h from /usr/include/vmmapi.h instead source one: for me it results vm_get_lowmem_size and vm_get_highmem_size missing... any ideas? I think we need to include lib/libvmmapi folder so includes are kept from /usr/include ones. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RE: wbem, cim and instrumentation
On Wed, 2014-05-07 at 08:39 -0400, Bruno Lauzé wrote: One thing I feel FreeBSD always ignored is instrumentation frameworks. I am talking about wbem, cim model and implementation like OpenPegasus. Why is that? I ported OpenPegasus to work in FreeBSD with few patches. However, of course without providers a wbem doesn't go far. I started to see how to shape providers for freebsd at: github.com/brunolauze/openpegasus-providers my openpegasus port is at: github.com/brunolauze/freebsd-ports/tree/master/net-mgmt/openpegasus Apple ships a wbem Microsoft ships a wbem / non-standard RedHat ships it. Suse ships it. z/OS ships it. Ubuntu and distro-like ships it. And Solaris does also. Why not us? The advantage outside of this idea is better coding technique and design to expose API first and utility based on those APIs. if any utility can be used as API, this discard the need for application to use system() or popen() to execute shell code to accomplish system tasks, which is really bad but widely widespread in lack of good API exposure of those utilities. This reduce a lot of error with changes in utilities switches, etc. and mitigate security risks. Wouldn't it be great to query FreeBSD with queries like: select * from UNIX_DiskDrive where Storage_Capacity 1000 or select * from UNIX_SCSIController WHERE LastErrorCode 0 Anyway, this is just to talk, let me know your opinions! Are you going to propose updates/new ports for these tools? sean Well, like I mentioned, it's pretty useless to publish my port of openpegasus if there's no effort to develop providers for FreeBSD. A task that I started working on when time permits it. My point was to see what people in FreeBSD community thinks about this, about instrumentation and OS exposure to this standard. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
wbem, cim and instrumentation
One thing I feel FreeBSD always ignored is instrumentation frameworks. I am talking about wbem, cim model and implementation like OpenPegasus. Why is that? I ported OpenPegasus to work in FreeBSD with few patches. However, of course without providers a wbem doesn't go far. I started to see how to shape providers for freebsd at: github.com/brunolauze/openpegasus-providers my openpegasus port is at: github.com/brunolauze/freebsd-ports/tree/master/net-mgmt/openpegasus Apple ships a wbem Microsoft ships a wbem / non-standard RedHat ships it. Suse ships it. z/OS ships it. Ubuntu and distro-like ships it. And Solaris does also. Why not us? The advantage outside of this idea is better coding technique and design to expose API first and utility based on those APIs. if any utility can be used as API, this discard the need for application to use system() or popen() to execute shell code to accomplish system tasks, which is really bad but widely widespread in lack of good API exposure of those utilities. This reduce a lot of error with changes in utilities switches, etc. and mitigate security risks. Wouldn't it be great to query FreeBSD with queries like: select * from UNIX_DiskDrive where Storage_Capacity 1000 or select * from UNIX_SCSIController WHERE LastErrorCode 0 Anyway, this is just to talk, let me know your opinions! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
install error with r263638
I am experiencing issue related to r263638.During a ZFS Install, it does create a new volume for /root but bsdinstall cannot copy root/.cshrc during base.txz extraction.Would we want to but ,canmount=off or change the way root profile gets created for zfs install? What could be the cause? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RE: vm_map.h
I suggesting this because it is used more ahead in the same file, but the other way around is fine for me From: j...@freebsd.org To: freebsd-current@freebsd.org Subject: Re: vm_map.h Date: Thu, 13 Mar 2014 14:00:59 -0400 CC: brunola...@msn.com; a...@freebsd.org On Wednesday, March 12, 2014 5:13:28 pm Bruno Lauzé wrote: The two defines in vm/vm_map.h #define min_offset header.start /* (c) */ #define max_offset header.end /* (c) */ are really getting in the way because those words are most likely to be used downstream. I would suggest renaming those defines to: #define vm_min_offset header.start /* (c) */ #define vm_max_offset header.end /* (c) */ Am I missing something? A simpler fix is probably to put the #define's under #ifdef _KERNEL. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
vm_map.h
The two defines in vm/vm_map.h #define min_offset header.start /* (c) */ #define max_offset header.end /* (c) */ are really getting in the way because those words are most likely to be used downstream. I would suggest renaming those defines to: #define vm_min_offset header.start /* (c) */ #define vm_max_offset header.end /* (c) */ Am I missing something? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RE: libinit idea
It's really good to read the comments and see people point of view on this topic. I totally agree RC system is really good and stable, easy and extensible. The main concern I have here is performance. Starting a system is really slow. Boot to X (with simple xdm) is minimum 25 secs and I just feel there's something to do to cut this delay. Date: Sun, 23 Feb 2014 11:33:30 -0800 From: list_free...@bluerosetech.com To: fjwc...@gmail.com Subject: Re: libinit idea CC: freebsd-current@freebsd.org On 2/23/2014 10:31 AM, Freddie Cash wrote: The main developer for systemd is very anti-portability and anti-!Linux. He had actively rejected patches that made his projects work on non-Linux systems. In order to port systemd to a non-Linux system, he wants you to first implement every Linux feature that systemd uses. systemd is a non-starter, and not with considering. It's pretty clear Lennart Poettering failed history. Perhaps the best examples of why systemd is an anti-pattern is this: systemd stores logs in a binary journal. After the Linux zealots have spent about two decades using binary system data storage as one of the reasons Windows sucks, that strikes me as particularly ironic. The RC system we have is proof you do not need anything more than bourne and a respectable amount of intelligence to design a good init system. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
libinit idea
https://github.com/brunolauze/libnit
I know there's really big debate about init system but here's my tentative to
propose a new model to replace rc.
Let's call it libinit but the name as no significance for now.
I started coding a library with the following architecture.
the main idea is to rewrite rc in C language.
a utility called system would act a little bit like service command does.
a folder would contains libraries instead of scripts inside [target]/etc/rc.d
so we can add as many librairies a user desire and interlink the order of each
piece among all like in rc.
each library would follow and expose the following pattern:
char **provide(); /* returns all the PROVIDE a library contains */
then for each provide() value the library would expose :
XXX_provide()
XXX_require()
XXX_before()
XXX_keywords()
and optionally:
XXX_canstart();
XXX_prestart();
XXX_start();
XXX_status();
XXX_stop();
and also:
XXX_mycommand(int argc, char **argv);
essentially repeating the rc.subr model
system utilty would source /etc/defaults/rc.conf, then source result of
rc_conf_files loaded
On init, /sbin/init would call /sbin/system init instead of running script
/etc/rc
on init, system would scan folder (let's suppose /lib/init.d and
/usr/local/init.d for now)
try dlopen() each *.so* files
and grab provide(); xxx_provide(), xxx_require(), xxx_before() and
xxx_keyword() for each one.
compile a list of service discovered and do an rcorder.
The benefits is to avoid firing so many utility to manage to init the system.
Replicating all small helper function from rc to C language like load_kld would
avoid opening a process and do real syscall at moment.
Heavily use pthread, waitpid, etc...
So instead of firing /sbin/devfs /dev rule -s 1 applyset
call direcly what's would run inside devfs - rule_main in
src/sbin/devfs/rule.c ...
cut the fat
here's an example to show /etc/rc.d/abi conversion to abi.c
abi.h:
#ifndef __ABI_H__
#define __ABI_H__
#include ../default.h
#define PROVIDE abi
#define REQUIRE { archdep }
#define KEYWORD { NOJAIL }
#include ../common.h
#endif
abi.c:
#include abi.h
int sysvipc_start()
{
if (load_kld(sysvmsg))
if (load_kld(sysvsem))
return load_kld(sysvshm);
return -1;
}
int linux_start()
{
return load_kld(linux);
}
int srv4_start()
{
if (load_kld(svr4elf) == 0)
return load_kld(svr4);
return (-1);
}
#define __canstart
int abi_canstart()
{
return is_enabled(sysvipc) || is_enabled(linux) ||
is_enabled(srv4);
}
int abi_start()
{
int err1 = 0, err2 = 0, err3 = 0;
if (is_enabled(sysvipc)) err1 = sysvipc_start();
if (is_enabled(linux)) err2 = linux_start();
if (is_enabled(srv4)) err3 = srv4_start();
return err1 err2 err3;
}
#include ../common.c
where common.h and common.c implement everything by default a little bit like
rc.subr does.
e.g: PID_FILE and COMMAND macros implement the start by itself, etc...
as you can see really similar to what we have in the script file...
Then the system utility would also allow digging into the libraries with
command like:
system accounting rotatelog
etc..
I uploaded a quick start to show some code and expose more the idea.
https://github.com/brunolauze/libinit
Thanks in advance for your comments.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Device File Creation Time
root@pcbsd:/dev # stat /dev/ada0 1895890688 97 crw-rw-rw- 1 root operator 97 0 Feb 18 10:52:11 2014 Feb 17 09:36:43 2014 Feb 17 09:36:43 2014 Dec 31 17:59:59 1969 4096 0 0 /dev/ada0 root@pcbsd:/dev # stat /dev/ada0p2 1895890688 103 crw-rw-rw- 1 root operator 103 0 Feb 18 10:52:05 2014 Feb 17 09:36:43 2014 Feb 17 09:36:43 2014 Dec 31 17:59:59 1969 4096 0 0 /dev/ada0p2 root@pcbsd:/dev # stat /dev/ada0p3 1895890688 105 crw-rw-rw- 1 root operator 105 0 Feb 18 10:52:21 2014 Feb 17 09:36:43 2014 Feb 17 09:36:43 2014 Dec 31 17:59:59 1969 4096 0 0 /dev/ada0p3 As we can see all files in devfs reports Dec 31 1969 as creation time. Can we look to manage this value to know when a certain device was installed? It would be really great to know when a disk was replaced. Would there be any other mechanism to accomplish this? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
in-kernel zfs and cryptodev
I am compiling zfs in-kernel and it's working pretty well. However to succeed building a kernel with : options zfs device crypto device cryptodev a patch is needed to rename sys/opencrypto/deflate.c which enter in conflict with deflate.c from zfs After renaming sys/opencrypto/deflate.c to sys/opencrypto/cryptodeflate.c and changing the filename in sys/conf/files everything works perfectly. Any opinions on this? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
