syscall list
Hi, I don't remember how to extract the syscall list from the kernel. There was an article some time ago about this, and checking the syscall address to make sure it was not changed in the kernel. Could anyone point me to this article? I've tried to google around but didn't find it. Best Regards ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Idea about 'skeleton jail' -- desirable jail features
In my opinion, FreeBSD is currently behind in virtual server implementations for a few reasons; It does not support multiple IPs in jails. Sure, there are patches, but the one here doesn't compile on 5.3-STABLE, for example. Support integrated into the base system would be neat. It would also be nice a jipconfig which lets the host system root user add IPs to the jails (perhaps a sysctl to control this behaviour? Sometimes it's not desirable to let jail root add IPs at will, while in other situations the jails root user is trustable and would be allowed to add IPs at will.) Also, there was a project for 4.10 if I remember correctly about interface virtualization, it allowed jails to have their own firewall, among other things. I don't know if this would induce a far greater load on the system (it would have to pass the jail firewall and then the host system), but, it's a really nice feature. On a totally off-topic subject, can we, faithful FreeBSD users, expect systrace support in the future ? > On Mon, Jan 31, 2005 at 11:13:04PM -0800, Justin Hopper wrote: > +> We are considering open sourcing all of our stuff, to contribute back > +> what we can to the OS that allowed us to build our entire company. I'd > +> really like to see what others have done to make jails more manageable, > +> as it seems like there is so much that can be done but not many people > +> are working on it. It seems jails have the potential to become an > +> incredible way to virtually partition servers, and it would not be that > +> hard to implement solid tools for managing them. We have things like > +> JID-aware top and tools for automated jail builds, but it would be > great > +> to work with some FreeBSD heavies to finish up clean development of > +> things like jail resource restrictions (CPU,MEM,#PROCS,etc) and perhaps > +> a clean and universally useful way to easily configure and launch full > +> jail environments. > > Yes, it would be useful (I mean CPU/MEM/#PROCS limits), but as I > understand > there are two kinds of opinions about jails. First is that it should be > extended and allow to create a real virtual server and second is that it > should be light-weight. > > +> Pawel had some really interesting ideas for jails, but it seems that > +> he's too busy to work on them at the moment. Speaking of which, his > +> multiple IPs patch for 5.3 is still broken, and I haven't been able to > +> find what the problem is =( > > Could you describe the brokeness? I've made some fixes a week or something > ago, I just created a patch against HEAD if you want to try it: > > http://people.freebsd.org/~pjd/patches/jail_2005020101.patch > > There can still be some remaining issues, but I don't have time for more > detailed tests. > > > The thing that can be useful IMHO is possibility to use > reboot(8)/shutdown(8), etc. inside a jail, but... > I'm unfortunately too busy with other (probably less interesting, but > profitable) projects. > > -- > Pawel Jakub Dawidek http://www.wheel.pl > [EMAIL PROTECTED] http://www.FreeBSD.org > FreeBSD committer Am I Evil? Yes, I Am! > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
basic programming questions
Hey, Sorry if this is a little offtopic, but I need some basic help with C. I'm not a programmer, but I need to get something done in C for a project. I need to do a console application, and as I've got some free time, I'd like to add bold sentences and characters with other colors (ie blue, red, etc), to make it prettier. As my C skills go as far as declaring variables, making loops, and knowing my way around pointers, I really do not know where to start looking for the header file including these functions! I also need a function to clear the screen (in order to re-draw it). Could anyone point me to the right header files, and perhaps suggest some programs that use these functions so I can have something to start with? Thanks! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: basic programming questions
Thanks! I'll give it a look :-) > That's not a flame. The library is called curses, there is a version > called ncurses. > > http://www.cs.mun.ca/~rod/ncurses/ncurses.html > > -Steven > > -Original Message- > From: Adam Maloney [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 10, 2005 9:59 AM > To: H. S. > Cc: freebsd-hackers@freebsd.org > Subject: Re: basic programming questions > > > On Thu, 10 Mar 2005, H. S. wrote: > >> Hey, >> >> Sorry if this is a little offtopic, but I need some basic help with C. >> >> I'm not a programmer, but I need to get something done in C for a > project. >> I need to do a console application, and as I've got some free time, > I'd >> like to add bold sentences and characters with other colors (ie blue, > red, >> etc), to make it prettier. >> >> As my C skills go as far as declaring variables, making loops, and > knowing >> my way around pointers, I really do not know where to start looking > for >> the header file including these functions! I also need a function to > clear >> the screen (in order to re-draw it). >> >> Could anyone point me to the right header files, and perhaps suggest > some >> programs that use these functions so I can have something to start > with? > > curses! > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "[EMAIL PROTECTED]" > > __ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > __ > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: basic programming questions
Hey, thanks a lot man, really appreciated :-)
Meanwhile the program has it's base already working, very nice since I
didn't touch C for quite some time now (I used to program when I was
younger, then shifted to system administration and shell scripting), but
I'm enjoying getting things done on my own :)
By the way, you know a link for a good and complete C manual for free ?
Oh, and BTW. I've ran across a problem. I think I knew how to fix this,
but it's beating me right now. Near the end of main() I printf'd some text
and am expecting a y/n response from user. I scanf("%c", &userfeed); right
after, but it printf's and ignores the scanf.
I might know what's going on, some characters on the buffer are not
"cleared", and so scanf is beind fed one of these characters. My memory
says that fflush() should fix this, but it's not working. I've also tried
getchar() but it didn't work either (or I did it in a wrong way).. I'm
missing something obvious here!
What should I do to correct this? And is my
buffer-not-empty-so-scanf-gets-a-waiting-character theory correct ?
Your curses program and the links the other people gave were great, thanks
to all :)
> On Thu, 10 Mar 2005, H. S. wrote:
>
>>Hey,
>>
>>Sorry if this is a little offtopic, but I need some basic help with C.
>>
>>I'm not a programmer, but I need to get something done in C for a
>> project.
>>I need to do a console application, and as I've got some free time, I'd
>>like to add bold sentences and characters with other colors (ie blue,
>> red,
>>etc), to make it prettier.
>>
>>As my C skills go as far as declaring variables, making loops, and
>> knowing
>>my way around pointers, I really do not know where to start looking for
>>the header file including these functions! I also need a function to
>> clear
>>the screen (in order to re-draw it).
>>
>>Could anyone point me to the right header files, and perhaps suggest some
>>programs that use these functions so I can have something to start with?
>
>
> Here's a little program I just wrote for you:
>
>
> #include
>
> main()
> {
> initscr();
> start_color();
>
> /* we want blue text on a white background */
> init_pair(1, COLOR_BLUE, COLOR_WHITE);
> color_set(1, NULL);
>
> clear();
>
> mvprintw(10,20, "Hello, world");
> refresh();
>
> endwin();
> }
>
>
> I compiled with:
>
> cc -o test test.c -lncurses
>
> and it demonstrates what you want :- clearing the screen and writing text
> in color at a specific location (10 down, 20 across.)
>
> If you don't need to position the text, you can use plain "printw" without
> the x,y. printw is like printf.
>
> Hope this helps,
>
> Aled
>
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
IP packets from host system showing inside a jail?
Hey, I've noticed something odd.. I'm using FreeBSD 5.3-STABLE with PF, on a dual xeon 2.4 system. I have two jails running for web and mail servers. Today I was testing something and needed a tcpdump, so inside a jail I started tcpdump as root. To my amazement, IP packets from the host system (IRC connections that should NOT show on that jail) were appearing on the tcpdump INSIDE the jail! tcpdump then became irresponsive quickly after capturing those, ^C wouldn't kill it and ^Z didn't nothing either. I had to login from another terminal to the host system, and killall -KILL tcpdump. Is this a known bug? IP packets from the host system<->internet should not be visible inside the jail. If you need tcpdump/uname -a etc, I'll provide these when asked. Regards ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
passwd & permissions
Hey,
I'm using FreeBSD on various servers for many time now, and there is
something that always bothered me. It is related to /etc/passwd and
/etc/pwd.db permissions.
I have custom (0640) permissions on these files. However, each time a user
changes his/her password, the system will reset the password file
permissions back to the original (rw r r). I'm not much of a programmer,
but I tried to change passwd.c source to do a execl() at the end of the
file (calling chmod). After trying it, the permissions were reset anyway,
so I added a perror("execl") and it says permission denied. Should be
because passwd dropped privileges at that part of the program. I've
thought about a cron job to fix the permissions every X minutes, but I'd
like a more "clean" option to this.
Where in the system can I change the permission-reset behaviour ? This
also happens, for example, with /usr/local/sbin/ (rwx rx x are my
permissions) after I upgrade any port, it will be rwx rx rx , and
/usr/local/www too.
I've edited the mtree/ files as it sounded like a good lead, but the
behaviour remains.
What should I do ?
Thanks.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: passwd & permissions
Hey, #define PERM_INSECURE (S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH) #define PERM_SECURE (S_IRUSR|S_IWUSR) Thanks, removing S_IROTH worked :-) While we're at it, what is the cause for the system changing permissions when I install a port ? (ie /usr/local/sbin and /usr/local/www) As I've said in my previous mail, changing the mtree/ files to reflect my desired permissions sounded logical, but either I failed some step or it isn't the way to go. > On Sun, Mar 20, 2005 at 01:26:57PM -0600, H. S. wrote: >> I'm using FreeBSD on various servers for many time now, and there is >> something that always bothered me. It is related to /etc/passwd and >> /etc/pwd.db permissions. >> >> I have custom (0640) permissions on these files. However, each time a >> user >> changes his/her password, the system will reset the password file >> permissions back to the original (rw r r). > > I think these files would be rebuilt by the pwd_mkdb utility. You > should be able to change it to rebuild the files with different > permissions. See the PERM_INSECURE and PERM_SECURE constant pwd_mkdb.c. > > (I'm not really sure about the wisdom of making passwd and pwd.db > have permissions 640, but I guess you know your system best.) > > David. > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: passwd & permissions
> On Sun, Mar 20, 2005 at 01:26:57PM -0600, H. S. typed: >> Hey, >> >> I'm using FreeBSD on various servers for many time now, and there is >> something that always bothered me. It is related to /etc/passwd and >> /etc/pwd.db permissions. >> >> I have custom (0640) permissions on these files. However, each time a >> user > > Be carefull not to get yourself a false sense of security. e.g. if your > goal > is to hide information about your users, there are many other ways > to get the info without having to open /etc/passwd or /etc/pwd.db > > example: > > /usr/sbin/pw usershow -a > > Ruben > > [/ttyp0] username:/home/username$ ./pw usershow -a [/ttyp0] username:/home/username$ (no output) Since pw is not setuid, if it can't read any of the passwd files, it will not print the full userlist. I have very customized (and tested, over the years) permissions on the whole filesystem. That is why I wanted to find out why some permissions get back to system defaults whenever I install a port. The most proeminent cases are /usr/local/sbin/ (gets back to rwx rx rx) and /usr/local/www (rwx rx rx and chgrp wheel, I have a different group owning the directory). Any idea about what to fix in order to make the system stop resetting my permissions when I install ports ? Thanks! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
A few thoughts..
Hey all, I've been using FreeBSD for a long time, it's my favorite OS and I use it on all my servers and most workstations. However, due to the nature of some of the servers, I've always wondered about something, tho. It is related to something deep in the OS. Let me try to explain. For example, assume a shell server. There are permission restrictions everywhere, to avoid users from seeing information that should be available only to the administrator (ie: dmesg,systat, vmstat, and so on). One could assume users won't be able to access the information provided by these utilities. Please consider the following example: [EMAIL PROTECTED]:/home/UNAME/] sftp [EMAIL PROTECTED] Connecting to 192.168.0.254... -- lan gateway -- [EMAIL PROTECTED]'s password: sftp> put /sbin/dmesg dmesg 100% 5392 122.4KB/s 00:00 sftp> quit [EMAIL PROTECTED]:/home/UNAME/] ssh [EMAIL PROTECTED] -- lan gateway -- [EMAIL PROTECTED]'s password: Last login: Tue Mar 29 19:36:42 2005 from WORKSTATION Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD ?.?.? (UNKNOWN) Welcome to FreeBSD! Before seeking technical support, please use the following resources: o Security advisories and updated errata information for all releases are at http://www.FreeBSD.org/releases/ - always consult the ERRATA section for your release first as it's updated frequently. o The Handbook and FAQ documents are at http://www.FreeBSD.org/ and, along with the mailing lists, can be searched by going to http://www.FreeBSD.org/search/. If the doc distribution has been installed, they're also available formatted in /usr/share/doc. If you still have a question or problem, please take the output of `uname -a', along with any relevant error messages, and email it as a question to the [EMAIL PROTECTED] mailing list. If you are unfamiliar with FreeBSD's directory layout, please refer to the hier(7) manual page. If you are not familiar with manual pages, type `man man'. You may also use sysinstall(8) to re-enter the installation and configuration utility. Edit /etc/motd to change this login announcement. "man tuning" gives some tips how to tune performance of your FreeBSD system. -- David Scheidt <[EMAIL PROTECTED]> [EMAIL PROTECTED]:/home/USERNAME]$ ./dmesg Copyright (c) 1992-2004 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.3-STABLE #1: Wed Dec 15 20:18:13 WET 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/??? Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Pentium/P55C (199.31-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x544 Stepping = 4 Features=0x8001bf real memory = 83886080 (80 MB) avail memory = 72318976 (68 MB) (changed hostnames/logins - 192.168.0.254 is a host on my lan) My "USERNAME" account doesn't have access to /sbin/dmesg, but I uploaded a /sbin/dmesg from a 5.2.1-RELEASE to a 5.3-STABLE box, and then I could have access to this system information. The same goes for systat , vmstat, and all these commands that (most people think) shouldn't be available for regular users. Shouldn't this information be protected at kernel level? Am I missing something I can do about this ? Because this method works with everything that ressembles permissions in order to hide system information that can be obtained without root privileges. Another thought, one can use the "logger" utility to write to some logfile that is accessible via syslogd. example: [EMAIL PROTECTED]:/home/UNAME/] logger -t su: evilone to root on/dev/ttyp0 # tail /var/log/messages Mar 29 20:14:11 WORKSTATION su:: evilone to root on/dev/ttyp0 If you can't trust your logs.. This also poses another problem, with a little patience, one can fill up /var. Lastly, anyone knows if FreeBSD is getting systrace support ? I think of it as a major drawback in the security field, one can do very interesting things with systrace. Added with other freebsd features (jails, etc), it makes a very good security tool. Any comments appreciated! Regards. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A few thoughts..
> On Tue, 29 Mar 2005 13:19:06 -0600 (CST) > "H. S." <[EMAIL PROTECTED]> wrote: > > >> [EMAIL PROTECTED]:/home/USERNAME]$ ./dmesg >> Copyright (c) 1992-2004 The FreeBSD Project. >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > [...] >> real memory = 83886080 (80 MB) >> avail memory = 72318976 (68 MB) > >> My "USERNAME" account doesn't have access to /sbin/dmesg, but I uploaded >> a >> /sbin/dmesg from a 5.2.1-RELEASE to a 5.3-STABLE box, and then I could >> have access to this system information. The same goes for systat , >> vmstat, >> and all these commands that (most people think) shouldn't be available >> for >> regular users. > > If you don't want users to run random binaries put /home and /tmp on > their own partitions and mount them noexec. Also note that users can > still read that info by accessing /var/log/messages and /var/run/ > dmesg.boot > I do want them to run random binaries, such as psybncs, eggdrops, shoutcast servers, etc. Mounting /home noexec isn't an option, /tmp is noexec tho. >> Shouldn't this information be protected at kernel level? Am I missing >> something I can do about this ? Because this method works with >> everything >> that ressembles permissions in order to hide system information that can >> be obtained without root privileges. > > Sounds like security through obscurity to me. If you don't trust your > shell users put them in a jail, where any bad behaviour can be > contained. > They need multiple IPs, and there are lots of users. Creating a jail for each user is not pratical in any mean (firewall rules, number of jails, disk space, to name a few). The ideal would be only root accessing this information, so users would need a setuid binary in order to be able to see such stuff. And since only the administrator could set the setuid bit.. This could be compared to what was done in FreeBSD lately, I remember in 4.7 (and probably later, up to 4.10 I think) a user could see the full connection lists (even connections from other users), only later the kern.ps_showallprocs/security.bsd.see_other_uids took effect for these matters too. I don't know how hard would it be to implement this kind of information containment in the heart of the system, and it surely could lead to many discussing about what should be hidden from users and what shouldnt. Personally, I don't like the hability of having users checking the kernel message buffer, or seeing the vmstat / tcp statistics etc. >> If you can't trust your logs.. This also poses another problem, with a >> little patience, one can fill up /var. > >> Lastly, anyone knows if FreeBSD is getting systrace support ? I think of >> it as a major drawback in the security field, one can do very >> interesting >> things with systrace. Added with other freebsd features (jails, etc), it >> makes a very good security tool. > > Have a look at mac(3), mac(4) and mac.conf(5), it's not systrace but you > can achieve > similar results. Systrace is much more complex than mac. > > Cheers, > -- > Miguel Mendez <[EMAIL PROTECTED]> > http://www.energyhq.es.eu.org > PGP Key: 0xDC8514F1 > > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A few thoughts..
> On Tue, Mar 29, 2005 at 03:12:25PM -0600, H. S. wrote: >> This could be compared to what was done in FreeBSD lately, I remember in >> 4.7 (and probably later, up to 4.10 I think) a user could see the full >> connection lists (even connections from other users), only later the >> kern.ps_showallprocs/security.bsd.see_other_uids took effect for these >> matters too. > > It needs time to implement and actually process such checks. I understand, and can only congratulate the freebsd developers for the nice programming you've all gotten us used to. I can't code C enough to be able to do anything really complex, however I do have a noction of how much effort is put into stuff like this. > >> > Have a look at mac(3), mac(4) and mac.conf(5), it's not systrace but >> you >> > can achieve >> > similar results. >> >> Systrace is much more complex than mac. > > That's a good one! It's actually quite the reverse, MAC is much more > powerful than systrace, simply because it operates on a different > level. You can do all this kind of checks with a MAC policy, if > something does not have the necessary hooks, complain to Robert Watson :) > > Joerg Hmm, I'll furthen my MAC knowledge then :-) > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A few thoughts..
Thanks for all the replies, I'm considering mounting /home noexec, and installing the most common stuff system-wide, so it can be executed by any user. As I stated previously, I'm not much of a C programmer, but I can do some coding. I've been thinking into changing the core of the system a bit to return errors if some information is accessed by a normal user. I'd like to know if getuid() would work that deep in the system? And how can I register sysctl mibs in the kernel ? For example, say I wanted to create a kern.disclosure.no_dmesg ; Assuming I could find the piece(s) of code that dmesg (talking dmesg here, but I'll try to change some other stuff too) ultimately goes to, how would I compare the sysctl kern.disclosure.no_dmesg to 1 or 0 ? A good paper on this would be a very nice lead. Thanks! > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On Tue, 29 Mar 2005, H. S. wrote: >> >>>> If you don't want users to run random binaries put /home and /tmp on >>>> their own partitions and mount them noexec. Also note that users can >>>> still read that info by accessing /var/log/messages and /var/run/ >>>> dmesg.boot >>>> >>> >>> I do want them to run random binaries, such as psybncs, eggdrops, >>> shoutcast servers, etc. Mounting /home noexec isn't an option, /tmp is >>> noexec tho. >> >> On another hand, you could provide safe and secure system provided >> binaries that they would have to use instead of compiling their own. >> which would solve the case and ultimately when upgrading the package >> provided to them would upgrade all the users at once without you >> having to worry about insecurities being scattered throughout your >> system. Now I could see if this was a development server then you >> obviously would want to allow your users to do such a thing but since >> you mentioned things like psybnc, shoutcast, etc... the thought to me >> doesnt resemble a development server. So my suggestion would be >> provide the software they need on a as-is-basis and take requests and >> mount the user partition with the [noexec] option and tune sysctl >> and operate in a secure level + chmod/chflag the proper files and >> make 1 jail for the whole user based part of the system for all that >> to run out of. >> >> Best of luck, >> --c0ldbyte >> >> >> -BEGIN PGP SIGNATURE- >> Version: GnuPG v1.4.0 (FreeBSD) >> >> iD8DBQFCSfZKsmFQuvffl58RAsw0AJkB6cLDGL4dsY9FAGrKZatn8+MotQCfeEX3 >> 5R8zcR7nyVJQL1dgub0/nj0= >> =h8hs >> -END PGP SIGNATURE- >> ___ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to >> "[EMAIL PROTECTED]" >> > > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A few thoughts..
> On Wed, 2005-Mar-30 11:06:53 -0600, H. S. wrote: >>As I stated previously, I'm not much of a C programmer, but I can do some >>coding. I've been thinking into changing the core of the system a bit to >>return errors if some information is accessed by a normal user. > > Wouldn't making /sbin and /usr/sbin mode 750 be enough? That's the "heart" of my question. A user uploading a dmesg binary to his homedir and then ./dmesg will overcome these permissions. People suggested making /home noexec, I'm still considering the implications of that in my scenario. > >> I'd like >>to know if getuid() would work that deep in the system? > > In general, system calls can't be used within the kernel. The uid and > gid could be determined by directly dereferencing curproc or the > thread pointer passed around in most kernel internal calls. Note that > the only checks the (non-MAC) kernel currently does is "root" or > "not-root" using suser(9) (apart from the checks in kill(2)). > Restrictions for non-root users are implemented using file > permissions. > >> And how can I register sysctl mibs in the kernel ? > > Look at sysctl(3), /sys/sys/sysctl.h and (eg) /sys/kern/subr_msgbuf.c > Thanks, I'll have a look, also will have a look at MAC. I think I have a completely wrong idea of what MAC does. > -- > Peter Jeremy > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A few thoughts..
> On Tue, 29 Mar 2005, H. S. wrote:
>
>> My "USERNAME" account doesn't have access to /sbin/dmesg, but I uploaded
>> a /sbin/dmesg from a 5.2.1-RELEASE to a 5.3-STABLE box, and then I could
>> have access to this system information. The same goes for systat ,
>> vmstat, and all these commands that (most people think) shouldn't be
>> available for regular users.
>
> dmesg is implemented as an unprivileged program that uses an unprivileged
> sysctl to retrieve the message buffer, kern.msgbuf. You can set the
> sysctl security.bsd.unprivileged_read_msgbuf to 0 to block unprivileged
> reading of the buffer.
>
Very nice, I didn't know this MIB!
Thanks for the tip :-)
>> Shouldn't this information be protected at kernel level? Am I missing
>> something I can do about this ? Because this method works with
>> everything that ressembles permissions in order to hide system
>> information that can be obtained without root privileges.
>
> In essense, yes. Historically, system information was retrieved by
> programs using /dev/mem, which required privilege. In that scenario,
> deleting or removing set{ug}id from /sbin/dmesg (et al) removed the
> ability to retrieve the information for an unprivileged user. Changes
> were made to limit the use of privileged programs, which represent a
> substantially risky approach (privileged code rather than a controlled
> interface), FreeBSD has generally moved to exporting system information
> using the sysctl MIB, which generally doesn't require privilege. Some
> system export MIB entries make use of access control to limit the export
> of system information -- for example, we export process information for
> use by ps(1) using sysctl, but the sysctls in question will check whether
> the user has the right to retrieve information on specific processes (such
> as with jail, or security.bsd.see_other_uids=0).
>
> However, this approach has not been taken universally with sysctls,
> because it adds moderate complexity to the implementation, and adding
> restrictions to many of the MIB entries isn't useful in most environments.
> Using the MAC Framework, it's possibel to construct a module that would
> restrict access to a broad range of sysctls -- however, this also prevents
> calls like gethostname() from succeeding, so this approach also would have
> to be taken cautiously.
>
I've just begun trying to understand MAC. Is it possible to block this or
that sysctl MIB to users using MAC? MAC is very complex, I had no idea.I
thought it was mostly about ACLs, but after a bit of reading, now I know I
was wrong.
> Robert N M Watson
>
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
>
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
imminent disk failure ?
Hi gang, I have a server running 4.X for almost two years now, without problems - rock solid as it should be - yesterday the server became unresponsive, now that I have access again, and while checking the logs, I found this as the last message before the unresponsiveness: /kernel: ad0: READ command timeout tag=0 serv=0 - resetting The next message is the system getting back on, 1hour later. I have not changed anything kernel-related on this system for a long time (jul 2004), just apply the occasional kernel patch and rebuild/reboot the system. I never encountered this problem before. Could this message mean this disk is giving its last breaths ? BTW- 4.10-STABLE system. Kind Regards ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
